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ABSTRACT 


The apparent lack of management of software maintenance 
within DOD and throughout the software industry has given 
ise to concern, as the costs associated with software main- 
tenance continue to increase. The major contributor to the 
rise in maintenance costs seems to be personnel costs as 
oppesed to hardware aquisition or computer ‘ime. However, 
to-date, it appears that little research has been conducted 
to attempt to resolve this problem. There also appears to be 
alack of any standard definition of software maintenance. 
This thesis discusses various models which have been devel- 
oped to attempt to predict maintenance manloading as the 
controlling factor in maintenance costing. I+ evaluates one 
model in particular, and proposes a possible maintenance 
versus life cycle phase relationship which may be of assis- 
tance to the software manager in maintenance manloading 
prediction. It also proposes specific topics for further 
research in this area. 
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A. BACKGROUND 


The department of defense for the last twenty *o thirty 


years has become more and more reliant on automatic data 


processing equipment to accomplish 2t+s seemingly ever 
increasing and complex mission. When this trend star«ed, 
hardware was ‘the overriding concern, consuming, on 955), 


more than 80 percent of the data processing dollar [{1j. 
Through the years, technical inovations, such as the evolu- 
tion from vacumm tubes to discrete transistors and from 
discrete transistors to integrated circuits, coupled with 
the increased use of mass production have decreased the cost 
of hardware. HOwEeVer, software has continued to rise in 
price. This rise in th2 price of software and +he decrease 
in the price of hardware has resulted in software rapidly 
becoming the more costly sf the two, and it is predicted 
fnae by 1985 it will account for better than 90 percent of 
the data processing dollar [2]. 

The true impact of this development may not appear to be 
Significant until one realizes that the value of this soft- 
Ware in 1973 was set at 20 billion dollars for the Urited 
States [3], and is estimated to be over 200 billion dollars 
ma 1985 (4 j. 

Mena direct result of the monetary value of softwa 
production, many techniques have been developed +o estinatea, 
eee ns Start, What the overall life cycle ccst of a softwa 
project will be. A recent study conducted by Hughes 
Aircraf*= Company for the Air Force examined twenty-one of 
these models to determine cemmonalities and differences in 


Sheir ccst estimating approaches. Ten of these models ars 





limited to software development cost, while eleven have 
software support cost as a primary or secondary output. 
Table I lists all of ‘the models studied, in alphabetical 
erader.{ 5] 

Originally, it was thought that development costs were 
the most important item to derive and/or estimate. In fact, 
the development and design efforts for a new system are 
indeed still looked upon as more enjoyable and rewarding 
than the maintenance effort for an existing system. There 


are, of course, many reasons for this view. Six of these 


reasons, according to Robert Glass, ate : 

1. Maintenance is intellectually very deece Veul st. 
Problems cannot be bounded. The cause could be 
anywhere. 

2. Maintenance is technically very difficult. Problems 
cannot be specialized. They could surface because of 
errors in the coding, design, architectures, OG 


ccncept. 

3. Maintenance is unfaic. Usually the person who is main- 
@eenangG a) product did not writs it and must interpret 
what the original author mean. Documentation is 
inadequate most of the time. 

4. Maintenance ils no - win. People only come to mainte- 
nance with problems. 

See Maintenance is infamous. Ther2 is very little glory, 
noticeable progress, or chance for ‘success’. 

6. Maintenance lives in the past. The general quality of 
eece DeInd Mazmtained 2s oftan terrible. This is 
partly because it was created when everybody's under- 
Standing of software was more rudimentary, and partly 
because a great deal of code is vroduced by peonle 


before they become really good at programming.[6] 
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However, more and more tesearch is being conducted on 
the maintenance aspect of software cost estimation. The 
treason for this is becoming apparent, as it has been esti- 
mated that from forty percant to ninety-five vercent of life 
cycle costs can be attributed to the maintenance effort [7]. 
The reason for this wide range of estimation seems to lie in 
the way various organizations view what constitutes 
Maintenance. 

The definition of software maintenance appears to vary 
with the organization and seems to be effected by management 
constraints. Software maintenance can cover the spectrum 
from correction of bugs caused by coding errors and design 
inadequacies to enhancements whose purpose is to add whole 
new ideas and/or design concepts not specified for inclusion 
in the original system. The lack of a standard definition 
Bor Maintenance isa major contributor +0 «he paucity of 
data collection in this area. In many organizations, ¢spe- 
Seally military, as top level management personnel rotates 
through specific positions, differant definitions of what 
constitutes software maintenance also rotate through these 
positions and the organizational levels they control. As a 
direct result, data collection reaquirements change to 
complement the definition of maintenance and, as a conse- 
quence, no consistent ‘track of a project's manpower usage 


history can be recreated. Of d2ea<=2o Silgnitecance is + 


(D 


she 
lack of @ standard maintenance policy within the ordaniza- 
tion to include a maintenance strategy which will add to the 
degree of software maintainability, if not assure it. 

In view of the large costs associated with software 
Maintenance, GAO conducted a study which reviewed fifteen 
Federal computer installations in detail. Their findings 
pointed to two major contributors to the problem; the fact 


that, in the majority of agencies, Maintenance is not 


14 





Managed as a separate, identifiable function, and there is 
an absence of a uniform definition of maintenance [8]. 
GAO's recommendations included development of a standard 
@etinition of Maintenance by th2 National Bureau of 
Standards and delineation of maintenance as a discrete func- 
tion by agency heads. In the interim, GAO developed a check- 
list of items, the consideration of which could reduce 
Maintenance costs. In the checklist is a set of categories 
for recording maintenance costs. These six categories appear 
to reflect GAO's definition of maintenance and as such, ar 
listed below: 

1. Modify or enhance software to make it do things for 


(D 


the end user that that were not requested in *he orid- 
inal system design. 

2. Modify or enhance software to make it do things for 
the end users that were called for in the original 
design but which were net present in the first oroduc~ 
tion version of the software. 

3. Remove defects in which the software does something 
other than what t+h2 user wanted ("does the wrong 
thangs"). 

4. Remove defects in which the software is programmed 
incorrectly ("does the desired calculation, but gives 
an incorrect answer'). 

5. Optimize the softwar2 +0 reduce the machine costs of 
running it, leaving the user results unchanced. 

6. Make miscellaneous nodifications, such as those needed 
=O interface wit new releases of operating 
Systems.[ 9} 

This “definition” appears to have general applicability over 
the broad spectrum of activities which can be and have been 
grouped under the category of software maintenance. However, 


Number one may cause problems in the context of maintenance 
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cost estimation techniques based on the Rayleigh curve. 
Since enhancements necessarily require some design/develop- 
ment effort by their very nature (they give the product 
capabilities not called for in the original design), the 
manning level in such effort would exhibit a rise and then a 
fall in magnitude in the Rayleigh fashion, thus creating a 
series of small Rayleigh curves within the maintenance 
phase. As long as this behavior did not vary greatly fron 
the normal maintenance effort for that project, it would not 
have much effect on the project. However, if the front end 
of the curve rose beyond some predefined maintenance support 
boundary, then it would indicate the presence of a full 
scale development project instead of a pure maintenance 
eeEOrt, and it should signal the completion of the old 
project and the start cf a new one. Therefore, because of 
the nature of the software life cycle, even a standard defi- 
nition of maintennace has grey areas and management judge- 
ment must be used in its application. 

The GAO definition does, as stated earlier, provide 4 
good, general definition of software maintenance and, as 
such, for the purposes of this thesis, software maintenance 


encompasses all of its cat2gories. 


Bee FROBLEM DEFINITION 


James F. Green and Brenda FP. Selby, formerly of the 
Naval Postgraduate? School, having reviewed Putnan's Software 
Cost Estimating Model, the Army Macro-estimating Model, the 
Lehman-Belady Model, and the Parr Model, have proposed a 
Gual theory for maintenance requirements estimation. They 
proposed that, if one considered maintenance to include all 
effort applied to a software project from the time that the 
product was teleased to the user, that the peak maintenance 


Manloading required could be calculated by computing the 
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inflection point on a Rayleigh curve for the total software 
life cycle effort. They further predicted that one could 
predict the minimum maintenance manloading requirments by 
computing the inflection point on the Rayleigh curve repre- 
senting the maintenance life cycle. 

The proposed Green/Selby Model, upon cursory examina- 
tion, appears to have tremendous potential as a tool for the 
manager cf software projects. However, Green and Selby were 
not able to obtain sufficient data tc thoroughly validate 
the applicability of the model to real world situations. 


Therefore, much further work is needed in this area. 


Ce. RESEARCH OBJECTIVES 


The objectives of the research are twofold: to evaluate 
+he Green/Selby model for prediction of maintenance costs 
via projection of maintenance manloading, both for mainte- 
nance team development and for outyear support resource 
estimation, and to provide an analysis of applications of 
the model in areas other than project management and 
control. The Green/Selby nedel addresses two areas, a mnain- 
tenance planning concept which is concerned with the overall 
Maintenance strategy as applied to a particular software 
project and a maintenance csontrol concept which is concerned 
with manloading requirements estimation. Only Ehe latcer 
will be dealt with in this research. 

The evaluation of the aodel will be accomplished in the 
pursuit of three subobjectives. The first is to provide an 
analysis of seftware maintenance costing problems and a 
Synopsis from the literature of oth xisting models and 
techniques, some of which were Seq In the inspeal 
Green/Selby model development, and some of which the authors 
feel are of equal importance and which may contribute to 


further development or application of the Green/Selby acdel. 
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The second subobjective is to validate the development of 
the Green/Selby model through analysis of the mathematical 
relationships and through recreation of the empirical devel- 
opment. The third subobjective is to validate the model with 
actual data from as many different sized software projects 
as possible to ascertain the degree to which the model is 
applicable +o real world software costing problems. 

Based on the results of the data analysis, projections 
will tke made as to possible applications of the model in 
areas other than cost estimation, if such applications 


appear to exist. 


Dem ASSUMPTIONS/LIMNITATIONS 


Three major assumptions were made at the onset of the 
research effort for this thesis. Other assumptions were 
necessary at specific junctures of the research but they do 
not apply in every case, so they are discussed where they 
are applicable. The major assumptions are as follows: 

1. I+ was assumed, based on linited prior study in the 
subject area, that the software voroject life cycle and 
all of its phases followed the general pattern of tho 
Rayleigh curve. 

2. It was assumed that the Green/Selby Model was valid in 
its development though not thoroughly tested in its 
application. 

Dae it Was assumed that there is little difference in how 
project size affects the manning behavior of a project 
during the individual phase cycles and during «he 
morale DEO TeCt Life cycle. 

Three major constraints were found to limit the research 
effort. They are as follows: 

1. There was found to b2 a serious lack of readily avail- 


able data which applied to the maintenance phase. 


18 





2. There appears to have been little major research done 
in the area of software maintenance manloading/cos« 
estimation. 

3. Because of the nature of the subject area and «he 
variance of maintenance data collection across organi- 
zations, the research completed and data collected +o 
date appears to have involved what are recently being 
categorized as inefficient and maintenance-intensive 
design techniques. Therefore, the applicability of 
early works and present research using old data may 


become suspect, if not invalid, by the use of such 


techniques as modularization, information hiding 
modules, and the use of other, recently developed, 
software tools. Hence, the new methods may alter the 


old relationships entirely. 


fee SESEARCH METHODOLOGY 


The research methodology implemented by the authors of 
this thesis was fivefold, to include literature search, data 
search/collection, research desiaqn, model validation, and 
data analvsis/evaluation. 

A literature search was conducted both by manual and 
automated means. A manual search produced most of the refer- 
ences, used by Green and Selby, which were used to provids 
the researchers with a solid background in the area of study 
and to ztecreate, as clossly as possible, +*+he knowledae base 
from which the Green/Selby nodel was develoved. Two auto- 
mated searches were conducted, one «through the Defense 
Logistics Informaticn Studies Exchange (DLSIE) and one via 
the computerized library search network. Both searches 
produced numerous writings of interest from the private and 


Military sectors. 
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The search for data highlighted the largest single stun- 
bling bleck to research in the area of software maintenance, 
that of a lack of adequate data collection by maintaining 
activities. Actual manloading records have usually been 
kept during the development phases of numerous software 
projects; however, Maintenance data appears to have been 
recorded only recently, and then only sporadically at best. 
The search for data was conducted successfully via telephone 
conversations with the following persons/organizations; 

Geddard Space Flight Center, Greenbelt, Md.; and 
Dr. Willa Kay Weiner-Ehriich, consultant, Bankers Trust 
SO., NY, NY. 
The following organizations were contacted in the course of 
the search with no Significant results: 
Data And Analysis Center for Software, Griffis AFB, NY; 
United States Army Computer Systems Command, Ft. Belvoir, 
ae 3 
Aeronautical Systems Division, Wright Patterson AFB, 
Dayton, Ohio; and 
Data Systems Design Center, Gunter AFSTA, Montgomery, Ala. 
Valuable support and/or referral information were received 
from the following persons: 
Dr. Robert Grafton, Office of Naval Research, Washington, 
ar « 5 
ieee ¥icctOr Bascili, Oniversity of Maryland, College Park, 
Ba. ? 
Mr. David Weiss, Naval Research Laboratory, Washingtcn, 
De Ce 5 
Ms. Cheryl Maloney and Mr. Robert Jones, United States © 
Army Cecmputer Systems Command, Ft. Belvoir, YVa.; and 
Mc. Lawrence Putnam, Quantitative Software Management, 


inec., McLean, Va. 
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The NASA SEL data base, which contains data on about 
forty software projects, was received from the Data and 
Analysis Center for Software, but it was discovered that 
Maintenance data is just now being collected, and no signif- 
icant aggregate will be available for approximately two 
years. 

A report, produced for the Air Force by General Research 
Merporation of Santa Barbara, Cas, indicated that the 
Planning and Resource Management Information System (PARMIS) 
at the Air Force Data Systems Design Center (AFDSDC), Gunter 
AFSTA, Montgomery, Ala., held a large, relatively untapped, 
data base of manpower usage (projected and actual) fron 
about 2000 projects. However, the data search revealed that 
PARMIS was teplaced by 2 new Personnel Cost/ Accounting 
System in 1977/1978 and it appears that the former data base 
was deleted due to format incompatibilities with the new 


system. 
As such, it 1s apparent that little maintenance data is 
available or, in Sune KS TenCe, 2t is very difficult to 


locate. 

Once a knowledge base was developed and data ccllected, 
the research process was begun. That process is listed in 
general: 

A. Develop mathematical relationships in terms cf equa- 
mons; 

B. Validate Green/Selby model development; 

C. Analyze empirical project data in terms of Green/Selby 
model; and 

D. Interpret data analysis. 

in order to attempt to validate the Green/Selby nedel, 
the model development was recreated as closely as possible 


uSing the same or similar data. 
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Data analysis was conducted by using various non-linear 
curve fitting techniques to fit actual life cycle nan- 
loading values to the Rayleigh model. Then, Green/Selby 
model relationships were calculated and plotted against 
Maintenance phase values. The above techniques allowed evai- 
uation of applicability of the Green/Selby model with actual 
project data. 


Pee OVERVIEW OF THE THESIS 


Pieenas introductory chapter, the term software ‘mainte- 
nance’ was defined and its importance in the context of the 
data systems organization was discussed. The propiem to be 
considered in this thesis has been presented and the objec- 
tives of the research effort intended to resolve the problem 
have been delineated. Assumptions made at the onset of the 
research effort and major limitations encountered during the 
course of the research wer] discussed. Finally, the research 
methodology was outlined. Chapter II looks at various 
models and cost estimating techniques which were used as a 
basis for the development of the Green/Selby model. It also 
includes a synopsis of other models which the researchers 
feel are of importance +9 the particular area of study. 
Chapter III presents an in-depth analysis of *he Green/sSelby 
model, and its propesed applications. Chapter IV provides 2 
Mathematical and empirical validation of the model, using 
Similar data +o that used by Green and Selby originally. 
Chapter V discusses the data analysis, and thus, the empir- 
ical model validation evaluation. Finally, Chapter VI summa- 
rizes the =hesis and presents conclusions and 
recommendations. 





Pee CORRENT TECHNIQUES USED AS A BASIS FOR THE GREEN/SELBY 
HOD EL 


J. Putnam's Software Cost Estimating Model 
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Putnam develoced his method for software cos 
mation by studing various systems designed by the United 
States Army Computer Systems Command (USACSC) and comparing 
them to the Rayleigh life cycle profile developed by Peter 
V. Norden in the 1960's, This life cycle profile, depicted 
in Figure (2.1), linked the individual cycles of each of the 
life cycle phases and added them together producing thse 
Peotile for the entire project. Putnam's empirical studies 


showed that, for the system studied, the software life cycle 


DEVELOPMENT MILESTONES 
TS 





PROJECT CURVE 


FUNCTIONAL 


TEST & 
ESIGN 
SPECIF. VALIDATION 


(20%) 





{ ~ 20%) MODIFICATION 


EXTENSION (25%) 


COGING Are 
ap. : ae ae 
‘ ee ail AGT 1084) 
~ os ' t 


’ 1 i 
| A} 6 8 oD ; 2 2.38 0 UNnax 


~ 


eo ere Ty ee. ere) 


~~ — 


q 

| 

: 

:. 

: 1 
| 

| 

| 
| 
| ! 
= ! 





D> eter Se SE: SE ae ee ee 


EEgGure 2. 1 Rayleigh Project Life Cycle Profile 





exhibits a rise in manpower up to a peak and then a trailing 
off portion corresponding very well with Norden's Rayleigh 
curve. 

Putnam attempts +9 answer the questions "How dot 
know how long a software project will take, and how much 
will it cost"? [10] In order todo this, Putnam analyzes 
the fcllcwing areas: 

eOptimum Man-loading over life cycle 
eTotal Manpower over life cycle 
eCost per year 
eLife Cycle cost in 

eCurrent $ 

eInflated $ 

eDiscounted $ (for £5. A.) 
eminimum $ benefits to break even over economic lifes 
eRisk profiles for: 

*Manpower 

eCosts 

eProject completion [ 11] 

The Rayleigh model for cumulative manpower utiliza- 

tion, used by Putnam, is given by the formula 
ze 
Coe Rie 2 ee (a) 
where 


Y = cumulative manpower used, 
K 


- v«< 


= the total number cr man-years of life cycle 
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curve shape? parameter, and 


he 
* = the elapsed time in years. 


(t+ 
2 i 
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However, most vopular form of the curve is «he deriva- 


rh 
O 
a 


tive form current manpower utilization expressed by 


ae 
Y¥" = 2kate . (Zeer) 


ie) 


mpirtically derived: 





2 
a= Va, ; (25:3) 


where 
t+ = the time to reach peak effort. 

In terms of software projects, t has been empirically shown 

to correspond very closely +o the design time (or the time 

to reach initial operational capability) of a large software 

Pea gect [12 j- 

With ¢t representing the development time for the 
system, equation (2.3) can be substituted into the Rayleigh 
equation, and the shape of the curve, together with the 
accompanving equation, allow us +o project what the manpower 
requirements and cash flow for system development will be at 
any given time. (Cash flow is calculated by multiplying 
manpower projections by the current personnel salaries.) 
The equation representing this curve is[{13] 

2 Byte 2e ; 
eC See d (2.4) 
d 

Putnam found that there was a fundamental relation- 
Ship in seftwar2 development between the number of source 
statements in the system and the effort, development tine, 
and the state of technology being applied to ‘the project. 
The equation that describes this relationship is : 

1/3 4/3 
Ss = Ck K 2 ; (2.5) 
d 
where 


SS 


*he number of end voroduct source lines of code 
delivered, 
K = the life cycle effort in nan-years, 


* = develooment tine, and 


OQ 
~~ 
il 


ieorde = 8On cnS Zechnology constant. 
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At least three different estimates of pregram size 
should be made before development of the system begins. 
They should be made once during the system definition phase 
and at least twice during the functional design and specifi- 
cation phase. This will insure a very realistic estimate of 
the size of the system. Admittedly, estimation of Ss and Ck 
are extremely difficult; however, if similar projects have 
been done in the past their values should remain fairly 
Gonstant.{ 14] 

Putnam's model seems to work extremely well with 
large scale software projects but it does not seem +o fit 
well for projects under 10,000 lines of source code [15}. 
The largest problem with the use of Putnam's model is the 
reliance on past experience and historical data banks, if in 
fact they exist, to estimate the size and complexity of the 
Seerent project. It also pays littl2 attention to operation 
and maintenance costs after development is complete or non- 
Manpower related items such as computer time and travel 
allowances which may influence total life cycl2 costs to a 
great extent. 


2. Parrts softwar 


oe 
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The Parr model was developed by F. Nj Parr after he 
had studied the work done by Norden and Putnam on the 
Rayleigh curve. Parr was concerned that the Rayleigh curve 
failed to answer questions about the learning curves usually 
associated with the start of new projects. He also fel+ 
eae at Made the assumption that the skill available for 2 
project depends con resources which have been applied to itr. 
Mmeees, he states, confuses the intrinsic censtraints of the 
linear learning curve with the rate at which software can be 
written, based on managemant's economically governed choices 


in tespense to these constraints. Parr further states that: 





The process generally used to develop new software can 
be epee ee of as the successive solution of a_large number 
of small problems. The solution of each of thése indi- 
vidual problems is a decision which defines some feature 
of the Final proegran. A developnent project corresponds 
to starting out with some fixed bounded set of problems to 
be solved and ending with enough decisions having been 
made for a working product to be available.[ 16 ] 


Parr utilized a binary tree concept to statistically 
determine the number of possible problems and decided that 
the proportion of the problems solved at time t, denoted as 


W(t), was given by the formula 


ee 
W(t) = 1/(1 + Ae ), (2.6) 
where 
A = a constant, and 
a = shape parameter. 
By solving this equation, he could determine the 


expected change in the size of the visible unsolved node set 
as a linear function of the work completed. The impor*ance 
of this was that he determined that the rate a+ which work 
could be usefully input +o the development process was 
proportional to the size of the set of visible unsolved 
problems, V(t). He further determined that when the optinal 
input effort is applied, steps in the development would be 
achieved at a rate proportional to V(*). Thus the work-rate 
could be determined by solving for V(t) which he developed 


into the equation : 


2 
V(t) = (1/4) sech ((at + c3)/2), (QT) 


where 
eee= ah i2cecrtation constant. 
Figure (2.2) shows the resulting curve overlayed on a corra- 
Sponding Rayleigh curve. 
ft can be seen that the back portion sf «he sech- 


squared function cerrelates very highly with the Ravleigh 
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Figure 2.2 Comparison of Sech? and Rayleigh Curves 


curve. However, the front pertion does not show a well-de- 
Mened starting point, as is the case with the Rayleigh 
curve. Pawoeceels BS tnat tne front porzion of the curve 
represents *hat portion of the work jione before the official 
Piercing date for a project. He feels that this is nore 
realistic than the Rayleigh curve. 

Parr went on +t9 explore the complexity factors 
introduced by the increased usage of structured programming 
and developed «he formula: 

=Ziaie mea G nae 
V(t) = (ade f {1 + Ae ) Va. (23) 

PAieebestte nd ~cleve has’ gts peak shifted slightly ‘*o 
Emeeraght of the seck-squared function; which predicts that 
peak work rate will occur after half the project has been 
gor >. PeR2=Ss He e@sSseszs 2S in keeping with «he theory that 


design may be slower, but there will be a compensating 
mi 


u 
GBeauction in testing and maintenance effort. 
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3. Army Macro-estinating Model 


Having already developed a number of software 
systems, the Army decided that it needed a method which 
would be simple, effective, and reasonably accurate for 
determining and controlling manpow2r and dollar resources 
for any point in the software life cycle. 

After reviewing the data on its existing systens, 
the Army chose the mathematical relationship developed by 
Norden where: 

=a % 
Y' = 2Kate. (2.9) 
This equation was the same one used by Putnan, and it was 
used by the Army to derive the various nilestones to be use 
by system managers. By comparing the actual resources used 
when these milestones were reached, the action officer could 
meee COrrective action if, Statistically, those resources 
used were outside the control limits. 
These milestones were developed based on step-by- 
it 


a 


4) 
(iD 


procedures given in the following cases: 


a 
“ 


ite System aiready under development (resources 


p 
g 
geted). 


4 
B 


Using budget data, +he maxinum level of manpower 


a. ) and the number 9£ years to reach maxinun effort 
ae is determined. Rather than compute the values for 
outyear manpower loading, Table II is used to compute thea 
values of Y' for the apnropriate Brae EV etuLeLolycng any 
entry opposite its time period py K, the appropriate number 
ef manyears are obtained. Tiewiseses Of K and © will deter- 


Mone the dinensions. 


Case Iz: New system (no f2source 3a%3). 
Total man-years of effort and peak time for manpower 
leading is derived using Baves' theorem. Based on empirical 
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data from internal systems, a probability versus K density 
function was derived without regard to type of systen. 


Further analysis determined frequency of ystem type and 


a 





probability of occurence of each typs. Using estimates 
based on past USACSC experiences (the average K value for 
all systems under development and average K for the func- 
tional type of system), initial estimates for a new develop- 
ment are calculated from regression graphs. Then, apvolying 
Bayes! theorem to average these individual estimates in the 
weighted probability sense yields a better estimate of K 
with a smaller standard deviation (i.e. better confidence in 
the estimate). To improve estimates and reduce uncertainty, 


Bayes' theorem is successively applied.[ 17 j 
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Le. As Belady and M. M. Lehman developed their model 
by studing the management and evolution of the 0S/360 oper- 
ating system. They felt that this system gave them a good 
view of the processes and managerial thinking that goes into 
the development and programming of medium to larg2-sized 
projects. The decision to use this system was reached after 
they had surveyed a number of versions and releases of 
OS/360 before their study becan. The data for each release 
included measures of the size of the system, the number of 
modules added, or changed, the release date, information on 
manpower used, machine time used and costs involved in each 
rel 2ase. Ej general, there were large, apparently 
Seeenascic, Variations in the individual data items fron 
release to release. 

The data exhibited a general upward ‘trend in ths 
Saze, complexity, and cost of the system and the maintenance 
process. This was indicated by comparing the comporents, 
statenerts, mist euee.o1s, and modules handled over the 
System life cycle. The various parameters were averaged to 
expose trends. When averaced, oreviously erratic data 
appeared to become strikingly smooth, displaying nonlinear - 


Dossibiy exponential - growth and complexity. 
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AS a result of their research, they postulated three 
laws cf Program Evolution Dynamics. 


os Law of continuing Se ee _ A system that is used 
Beet gees continuing change until it 1s judged more cost 
effective to freeze and recreate it... 

Software does not face the physical decay roblems 
that hardware faces. But the power and logical flexi- 
ee ey of computing systems, the extending Boo Ogy OF 
computer applications, the oe Aas hatdware, and the 

ressures for the exploitation of new business opportuni- 

les all make demands. Manufacturers, therefore, 
encourage the continuous adaptation of programs to keep in 
step with ee ee Sere EisrG ie, cub belon, sand OPDOr= 
mum ity. In addition to such external pressures for 
change, there is the constant need to repair systen 
faults, whether ee Jee scmrers that’ stem izoen faulty 
implementation or defects that relate to weaknesses in 
design or behavior. Thus, a programming system undergcees 
continuous maintenance and development, driven py mutuall 
stimulating changes in system capability and 2nvironmenta 
usage. In fact, the evolution pattern of a large progran 
m> Similar to that of any other complex system in that it 
seems from the closed-loop cyclic adaptation of environ- 
ment to system changes and vice versa. ; 

As asystem 1S changed, Mes StEUGEUGS » Ineviceoly 
degenerates. The resulting systen complexity and reduc- 
tion of managerability are expressed by the S¢cond Law of 
Program Evolution Dynamics. 

mrs Law of increasing entropy. The entropy of a 
system (1ts unstructuredness) increases with time, unless 
Pepecitic WOrk is executed to maintain or reduce it. 

This law too expresses vast Ho ee et zn jPare by 
data...This in turns eacs £0 Elche  fOnMubatton, Of the 
Third Law of Progrem Evolution Dynamics. 

I. Law of statistically smooth growth. Growth 

trend measures of fe system attriputes may appear =O 
Mensctechastic locally in time and space, but, statisti- 
a) iiteveace =cyelically self=reguiating, with well-de- 
faned long-range trends. ; 
_ The systen and the nmetasystem -*the preject organiza- 
tion that is developing it- constitute an organism that is 
constrained by _ conservation laws. These laws may be 
Mmecatliy violated, but they direct, constrain, control, and 
thereby regulate and smooth, the ion = [22m GEOweh Fand 
development patterns and rates. Observation, measurement, 
ema interpretaticn of the latter can thus be used to plan, 
control, and forecast better the product of an existin 
process and to improve the process so as to obtain desire 
Seedesirahble characteristics.[( 18} 


Having postulated these three laws, they commenced 


the process of defining a complexity factor C(8) for the 
various progran releases, each of which were assigned 
Release Sequence Numbers (RSN's). From the available data 


they prceposed the formula: 


Cee ee, 1; (em) 
R R R 





where 
M(R) measures the size of the the system in 
modules and 
M(HR) records the number of system modules 
that have received attention. 

O21 11 ZAG this complexity factor, they stated that 
the design - programming - distribution usage system has a 
feedback driven and controlled transfer function and an 
input-output relationship. This feedback results, some- 
times, from constant pressure to supolement system capa- 
mete y and power. This constant pressure normally results 
in work pressures building up as growth rate increases. 
Meeordingly, the growth crate increases the size and 
complexity of the system and reduces the quality of design, 
Seeing, and testing. This is accompanied by lagging docu- 
mentation, and other factors, which emerge to counter the 
increasing growth rate. 

Eventually, the above relationship resulted in the 
need for a systen Gonsorsdat20n in “which Scorrection, 
restructuring, and rewriting were done with few, we way, 
functional enhancements. The consolidation often results in 
the shrinking of a system during such a release, rathér than 
the growing normally experienced with each new release. 
This, they observed, occurred with every twenty to twenty- 
one releases of the systen. They ‘further observed that 
successful releases appeared to have an upper beund of about 
400 mcdules. 

Since the majority of managers base their decisions 
On available budgets, Lehman and Belady proposed that «the 
M@ral expenditure for all activities involved with the 
project be sequal to the budget, and hence, che formula for 


the budget (3) is given by: 


Bs P+t+A+e#ec (ee) 
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where 


Eee counties Of Leagint SxXtraction activity 

termed progressive, 

A is the amount of resources associated with 
documentation, administration, communication, 
and learning activity termed antiregressive. 

C is the increasing work demanded +o cope with 


the neglect of A, and is given by the formula 


c 
C= - (1-m) kPdt, and (Zea) 


where 


mand k are defined below. 


The formula for antiregressive activities is: 


A = mkP (Z2eni3) 


where 


m is the managemen+ factor, which is the 

EedceioOn, OL pecgress, KP, that is actually 

dedicated by management to A activity, and 
k represents the inherent A activity required 

for each unit of P activity so that complexity 

does not grow and is given by the fornula 

k= A/S P. (2. 714) 

Management .1s assumed to have full . control of the 


eeerocation of itS resources and the division of effort 
between P- and A-type activities. Management ,cannot, 
Mmemever, directly control the growth in. Complexity that 
accumulates, except by utter concentration on complexity 
memcrol through restructuring. This :s an activity that 1s 
Strictly antiregressive and, as such 1s psychologically 
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apid work leads to greater oressures on the team, and hence 


Meeeraicult to inspire Sees t ya eclds no Gizect,  short- 
m, benefits. 9 4 


An interpretation of their model suggests «hat mor 
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iD 


en 
Srrors. En Ces 2) eur a, requires greater repair 


eeevity. However, the data indicates that this problem is 


Mainly incurred in the same release rather than discovered 


and undertaken thereafter. PitneEIO&=,as=7ece Lt apdDears to 
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lead to an increase in the fraction of the system handled, 
it suggests that the maintenance teams tend to remove the 
symptoms of a fault rather than to locate and repair its 
cause. This problem is reduced through proper communica- 
ron, documentation, and learning by the programming 
team. [20 ] 


Bee OTHER MODELS OF INTEREST 


1. ge Model 


QSED a aes SS 


Randall W. Jensen {21] stated that, because tradi- 
tional intuitive estimation methods consistently produce 
Mecamistic results which contributes to the too familiar cost 
overrun and schedule slivpage, customers for software prod- 
ucts are becoming less willing to tolerate the losses asso- 
ciated with inaccurate estimates. He, therefore, derived 
his model based primarily on the work done by Norden, 
Putnam, and Doty Associates. 

In conjunction with the familiar Rayleigh equation 

2 


-3 + 


at 
Y' = 2Kate, (215) 


Jensen's model consists of a series of equations for systen 


Productivity, InatzaL project staffing rate, system 
complexity, systen Size, development effort, and risk 
analysis. 


He defines the productivity relationship by «he 
equation: 
=3 


mn = © (Kt), (2m 15) 
: d 
where 
PR = average project SsOduc<iVifY (source 
lines ver vear), 
Me= o62al Late cycia ccest in 2anveatrs, 


Cie, 





a = development time in years and is defined 
as the peak time for the Rayleigh curve, 
C = a proportionality constant, and 
B = slope of productivity relationship. 


While +his equation is not actually related to the 
Bpocem difficulty, it is related to the rate at which staff 
is applied to the task. EVeucIvely,  DrEeguectivity is an 
inverse function of the number of people directly involved 
with a development task due to the associated losses caused 
by the number of ccmmunication paths in the organization. 
This phenomenom can be accounted for by utilizing the 


relationship 
2) 
4 = ae (27) 


omen is the formula for the initial project staffing rate, 
Me and is extremely important in datermining the optimun 
project staffing rate. 

Most, if not all, of the projects studied by Jensen, 
appeared to demonstrate a consistent pattern which could be 
used to classify each project into distinct categories. 
These categceries were dependent on the interface complexity, 
logical complexity, and the percentage of new development in 
the system, all of which seemed to be defined by the ratio 


3 
K/t . PA | 
/ 4 ( ) 


The expression Kye, in a practical sense, represents 
femeetucal equilibriua ween the ilfecycle cost and devel- 
Opment time for a specific class of software orojects. As 2 
result, similar projects tended to naintain this equilibrium 
so that as the system size increased, the develcoment 
schedule increased correspondingly. This equilibrium also 


Maintained the staffing rate, 
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2 
Kst , (2. 19) 
‘ a 


within bounds that could be effectively accommodated by the 
pro ject. Thus, he used this @quilibrium expression to 


define system complexity (D) as 
D= Kft. (2.20) 


The value of Dcan be thought of as a limiting 
parameter in determining the minimum development ‘time that 
an organization can achieve for a given software project. 
Table III shows the values of D determined by Jensen from 
Putnam's analysis of USACSC data. 

The next equation, developed by Jensen, was referred 
to as the software equation, relating the size of the system 
to the technology being applied by the developer in the 
implementation of the systen. In deriving this equation, 
Jensen utilized an extension of the productivity relation- 
ship proposed by W. F. Sampson of General Electric Company. 

Sampson (22], after reviewing data supplied by 
Puenam from 19 USACSC projects, determined that only a 
Subset of these projects represented a consistent develop- 
ment environment and were sufficiently documented to be of 
value in establishing the model parameters. Evaluation of 
this refined set of data obtained a B value of -0.50 for the 
basic relationship between productivity and project stress 


Mmscead Of the -0.667 obtained when all the data was used. 


With Sampson's work in mind, Jensen derived the 
software equation tc establish the rate of source code 
development, dSs/dt. In his develooment, he assumed that 


Smee OOr.-10On of the project effort ievoted to code produc- 
fron, Pi(t), was characterized by a Rayleigh curve, which 


Was complete at td. 


tad 
~~J 





TR BLS  YEt 


Project Complexity Values 


alue | Characteristics 


8 Applies to new systems with significant inter- 
face and interaction reguirements within a lar- 
oot system structure. Bee Soa system and real 

ime processing developments with large percent- 
ages of logical code ate typical of this class 
of systems. 
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{ Applies to new standalone systems developed on 

feo 2e m eee systems. The interface problem 

with the underlying operating system or other 

arts of the system 1S minimal. New applica- 
ions software is typical of this class of sys- 

{| tems. 

| 

| 
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Applies to complete rebuilds of existing stand- 
alone systems where najor portions of existing 
logic can be used. 


al 


Wn 
cn 


Applies +o composite systems where existing 
tems are combined or integrated with little 


| | no modification of existing software. | 
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meen if 


te a = 6, (2. 21) 


where 


el = the time of peak manloading on the Rayleigh 


_ curve, ccincidental to development time, and 


d a 2 -(3t st) 
P (t)dt = ; (K/t ,)te deid= = 029576, (2. 22) 


then the burdening rate for this project is 
- 
d 
P(t) dt 0.3934K 
me en ee nee ee Oe = - - = 2.49, OR 


a 
d 
J Pattie ac 
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where 
D(t) = staffing level. The rate of source code devel- 
opment, dSs/dt, is assumed to be proportional to the rate of 
code production, P1(t) so that 
Ss = 2.49 PR P(t), 


and 
—_ 2 ee aoe eo} 
Ss = 2.49 PR 87S d +a aerde (2.24) 
= 2.49PR K/6. 
ae: ; — mens) 
Substituting the empirically derived value of PR = Oa 
gives: 
S (2.49C Joy Koe 
s = : 
1 a” 
Gyles 
So = CNK ti. (225) 


which is the software equation where 
C= a developer technology constant. 
MitcmmeeeCinelodgyvere Onstane, Ct, iS a factor, of 
constant of proportionality, that allows the user to relate 
mae system size, Ss, the life cycle effort, K, and thse 
development time, one for any specified project. The 
constant accounts for all variations in the life cycle 
effort fer projects which have similar size and scheduls 
properties. The constant is then a neasure of the develop- 
Bees production technology, cr ability to implement the 
Eco ject. This includes such factors as the availability of 
computing resources, crganizational strategies, developme 
tools and methodologies, familiarity With the tarde 


Computer, ctc. 





The technology constant considers two aspects of 


production, the environmental aspect and the technical 
aspect. The environmental aspect includes those factors 
dealing with the baSic computing environment. The environ- 


mental factors determine a technology constant which 
normally ranges between 2000 and 5000, with higher values 
characteristic of higher productivity environments; ec 
Boom’ pPtinitive tools to dedicated advanced tools and 
resources. The technical ispects of the technology constant 
are accounted for through the use of adjustment factors 


applied to the basic technology constant by use of the 


formula 
C & Ale f= Co f= (2.26) 
t tbh Visi i tb + : 
where 
oa = basic technology constant, 
f = ith adjustment factor, and 
ab 
a = total adjustment factor. 


The adjustment factcrs include those effects which are 
beyond the basic develcpment environmen* ard are project 
Specific. The factors, which are shown in Table IV, are 
examples of those found in a command and control systen 


environment. 


Feeling that his model could be understood better as 
a kiinear oprogrémming problem presented in a graphical 
fornat, Jensen defined the additional formulas which he 
@euld use for this forum. The first formula was for «he 
development effort (=) which he derived as: 


d 
2 ‘e Bey d= 90. aK- (2am) 
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TABLE IV 


Technology Constant Adjustment Factors 











Sacro = { Value | 
! Number | Description | Yes No 
ce ------—-7—----— ees, 
1 i Special display requirements Te 14 1 4.00 | 
2 | Detail operational requirements i 1.00 | 1.54 
| 3 | Changes to operational require- cg ols: | 1.00 | 
| } ments 
| 4 Real time operation | 1.33 | 1.90 | 
5 | CPU memory constraint | Arras: | 1206 | 
| 6 i cPU0 time constraint feiss te tec. 4 
u | First software developed on CPI | leo | 00 | 
| 8 | Concurrent ADP hardware deo? (7 1e00 4 
{ development | | 
| 9 | Peenee ecey ee at | tele. | 1.00 | 
10 | Development at operational site | 1.39 1.00 | 
11 : Development computer different | Jane | Tao0 | 
| | than target computer | | | 
| 12 | Development at multiple sites | 12025 | Te 00 | 
! We | First use of languags 1.80 | Veo | 
! 14 | MIL-STD documentation | 7249 | PONS, | 
io = oe ee 
The next was a relationship (8) determined by the systen 
size and the developer's approach to «he project and was 
given by: 
R = Ss/C = VRE . (2523) 
Maen, Uueilizing the fermulas for WN and D, equations (2.17) 
ea (2.20), where M represents a fixed staffing rate or 
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Management stress curve, and D represents projects 
complexity, he could plot all these equations on a 


surface for various size projects as shown in Pigure 
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Bagure 2.3 SSE oe Seales a Model Solution Surface 
(Graphical Representation) 
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once all 





jmme constraints, oD, R, MN, E, and *, are plotted on the 
solution surface as shown in Figure (2.4), some of the 
constraints will be eliminated from futher analysis by the 
manner in which other constraints intersect to form the 
bounded region. If the constraints bound a null region, 
either the cost or schedule is too optimistic and cost or 
schedule overruns in software development are likely to 


Becur. However, by utilizing the values for K and Be 
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Pigure 2.4 Feasible Solution Regicn 


Obtained from the graph and substituting into the Rayleigh 
Paweation, the optimum staffing profile (Y') can be cbtained. 

Recognizing that the calculations made by the model 
asSume that the input parameters are axactly known, and that 


there is a degree of uncertainty associated with each of the 
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input parameters, Jensen postulated, for risk analysis, that 


the deviation from the mean can be calculated using the 





relationship 
hh 2a PA Ot es 
of =[{ (ef/dSs) o + (df/0C ) o + (df/aD) FO j ; 
S t SC D 
where 5 
f= s = 5/1380.) AJ DO; 
ole : 


ith 
ll 


fain 
K = [ (Ss/C,) D}) . (2.29) 


Similar expressions for f could be found by using 4M, 
instead cf D, as the bounds for the feasible region. Os 
cases where both M and D interact, the expression for f 
should be considered invalid and no alternative solution was 
provided.f{ 24] 

AS an example of this risk analysis technique he 
provided the example where Ss = 55,642; 0D = 15; s = 2,058; 
m= i: and t = 0.482. The results were then plotted as 
Bio wn in Pigure ot Nic The results show that the 
probability of meeting the required schedule is 94 


percent.f[ 25 ] 


2. Other Models 


A description of some additional models which wers 
not used in this thesis but the reader might find informa- 
tive are provided in Appendix A and Appendix 3B, as described 
Byers Thibodeau and R. W. Wolverton, respectively {26,27}. 


C. CHAPTER TWO SUMMARY 


The thesis of the models used in this chapter and in 
Members chat were found in the iiterature, was to try and 
give management a tool with which they could predict the 


Meee Of SOftware, the time for producing this software, or 
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Figure 2.5 Risk Analysis of Schedule Using Graphical 


Technique 
Boh. Most, if not all of the models require the use of 
istorical data and/or management's previous experience as a 


portion of the predictive process. 

It was Putnam's view that software production followed a 
Rayleigh curve. This curve, he asserted could be calculated 
mem2zZzing historical data <¢to determine the technology 
constant (Ck), and the estimate of source lines of code for 
Maas type of preject (Ss), plus the budgeting information 
for the total number of man-years for the systems life 
cycle. 

The Army Macro model utilized Putnan's technig 
at various time increments, would compare actu 
With those predicted and, if the actual rescurces 6 
were statistically cutside some preset contro 
corrective action would be taken. 
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Parr felt that Putnam's model did not take into account 
the effort that was completed prior to the actual starting 
date. He, therefore, proposed a model which would take this 
work into account in the early part of the project. It also 
correlated well with the work done by Norden and Putnam with 
the Rayleigh curve, both at the peak level and in the later 
stages. 

Lehman and Belady found in their study of the evolution 
ef the 0S/360 operating system programming effort that, as 
the size and complexity of each release which contained 
functional enhancements increased, so did the number of 
errors and, thus, the amount of naintenance effort also 
increased, Therefore, ‘they postulated that for any system 
there is a time when it is better to restructure and consol- 
idate than to continue with additional enhancements. 

Jensen felt that Putnam's model reguired some expansion 
and refinement. This he attempted to accomplish through the 
use of linear programming and graphical representation of 


his results. 
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The GreenySelby model includes two techniques: the first 
characterized by a macro approach and the second by a micro 
approach. The results of the application of both techniques 
to project olanning parameters are compared and then weighed 
against managerial and organizational constraints to analyze 
tradeoffs and produce cost estimates. 


A. MACRC APPROACH 


The macro approach is concerned with man-loading across 
the life cycle of the project and, in particular, the mnain- 
tenance phase. The basis for this approach is derived from 
the relationships pioneered by Norden and further developed 
by Putnam. AS was stated in chapter two, the various phases 
of the software project life cycle have been found, ai) 
general, to be characterized by the Rayleigh curve function. 


mre LYNCtTLON is written as follows: 


-a + 


tnd 


= 2kKate 5 (S21) 


¥6 


; 
< 


Y" = manloading at any time +t, normally neasured in 


manyears Or manmnonths, 


t = elapsed time from the start of the project, 

k = the total accumulative manpower utilized over the 
project life cycle, measured in manyears or 
manmonths, 
and 


a= the shape parameter of the curve. 
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Norden demonstrated that the shape parameter (coefficient), 


a, Can be calculated by the equation: 


ec (3.2) 


4+ = the point in time of maximum manpower utilization 
for the project. 

It must be noted here that ee Mmeoduae2 One (si. 2) 8Can, In 
large projects (defined by Putnam as those projects with 
about 75,000 source lines of code {28]), be equated to 
project development time. In other words, large projects 
have historically been characterized by maxinum manloading 
at the end of the development phase, roughly when the 
product was delivered tc the user. However, it has been 
mound empiricaliy £29] that for other than large projects 
{less than 75,000 source lines of code) ¢_ actually falls at 
some point between t and the end of the development phase. 
This may or may not affect the Green/Selby model. The end 


= 


of the development phase will be denoted as oe ; Bi ire 


it 


a 


rs 


ct 


ev 
Mecz does not coincide with +. Putnam has indicate tha 


et SMall projects (less than 18,000 source lines of code) 


y! is reached at about t /W6. Medium sized projects 
max eV 
(18,000 - 75,000 source lines of code) reach Y' somewhere 


max 
between ¢ JV6 andt Vimeo Veer nerekore, = , ' in this 
thesis, SAL be Eaten | as the *+ine at which Y' reaches a 
maximum. 

Subs-2tuting equation (3.2) into equation (3.1) gives 
the follewing equation: 


2 2 
2 -t /2¢ 
Y' = K/t te 5| ote (3. 2) 
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This equation can be used to calculate Y' at any point on 
the curve once K and t_ are known. The calculation or e¢sti- 
mation cf K and t_ have been sufficiently dealt with in the 
literature and so they will not be addressed here [31]. 
However, it must be noted that t = Be at the point of 
maximum manloading, andso, at that point, equation (3.3) 


breaks down to: 


bay = K/t 3. (3.4) 


Norden also stated that the Rayleigh curve exhibited an 
inflection point where the decrease in manpower usage slows 
Mewn in the descending portion of the curve £32], as charac- 


terized by the equation: 


W2 
t = (3/2a) ,” (3.5) 


where 
“= tHe cite Of the inflection point of the Rayleigh 
ip 
curve, and 
a= the curve shape parameter 
The Green/Selby model is based in the theory that Y'. 


can be defined as a maxinun level of maintenance effort 


ithe 


@ project. The minimum level of mnaintenance effor+ is 
defined by yr! toed Slevw2merecction “BGant cn the curve for 
<he Weer cer siase, which, for large projects in general, 
has been said in the literature to follow the Rayleigh 
Baetetn. The definition of £, as a maxinum level of nainte- 
nance was further supported® by the hypothesis that the 
maximum level of manloading during «he maintenance phase, 
foe, WAS equal tO the manloading at the inflection point 
yt 


an 
ww ad 


=| 


This hypothesis appears to be based on the assumption 


“the maximum point of the naintenance phase coincides 


so ct ot 


, t $e 
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both in time and in magnitude with the inflection point of 
the life cycle curve. Green and Selby used the empirical 
deta synthesized from a spectrum of USACSC projects to 
develop the theory. Figure (3.1) depicts their theoretical 
model. 
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Pigure 3.1 Normalized Rayleigh Curve 


fee TCRO ASPOROACH 


The micre approack was developed »b Green and Selby 


y = 

using raw manning data obtained from the IBM Federal Systens 

Space Shuttle Progran and the unpublished papers cf Mr. Kyle 
co 


Rone cf IBM. This approach uses a matrix technique coupled 
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with work breakdown structures to project maintenance 
Manning requirements. The raw data was synthesized by Green 
and Selby to fit the macro model and then compared with the 
results cf the micro matrix method. The authors of this 
thesis were not able to obtain data of sufficient complexity 
and refinement to apply micro techniques to it, and, *there- 
fore, the micro approach will not be discussed further in 


this work. 


C. PROJECTED MODEL APPLICATIONS 


The Green/Selby model was presented as a management 
tool. The control concept coupled with the planning concept 
appeared to be a total maintenance strategy package for the 
project manager. The model cculd provide management with the 
determination of a maintenance support level by use of the 
Mmmeeecction point predictors (Y¥*' . and YX! VP toe cetine 
maximum and minimum maintenance aac oeats Ree ak lon bounda- 
ries. These boundaries, coupled ith a planning strategy, 
provide a powerful planning tool. 

Use of the model was also projected for forscasting of 
resource distribution via integration techniques applied +o 
the area of the curve under the naintenance support boundary 
to break out manpower required by separation of development 
work (enhancements, additions, new design) from pure nainte- 
mamae WOrK (debugging, design error correction).f[ 33] 

The model was finaliy projected as a device for moni- 
BOring configuration control. Drawing on the work of Lehman 
and Belady, Green and Selby theorized that, @as a project 
moves from pure "fix-it" tyne naintanance to nodifications 


which may eventually lead to a new release of the product, 


the complexity of the product increases. This rise in 
complexity increases the maintenance level. AS successivé 
releases are developed, the maintenance level increases 


=) 





until it eventually exceeds the original maximum maintenance 
support level of the product. This would then predicate 
Management assessment of the viability of the project from a 
cost effectiveness point of view, as the project will have 
reached what Green and Selby called a maintenance budget 
Saturation point. At this point, or earlier, depending on 
Management policies and desires, the old project would be 
terminated and a new life cycle/Rayleigh curve started. 


DS CHAPTER THREE SOMMARY 


The Green/sSelby model appears to provide an easy-to-use 
cost estimation tool for the data systems manager. The macro 
and micro approaches give fairly quick estimates of mainte- 
Mance manloading which can be cross compared and coupled 
with management constraints to fill out the system manager's 
overall strategy. If valid, i+ seems to partially fili the 
void in data systems nanagement, alluded to in the GAO 
report, that of the lack of a maintenance strategy inan 
Organization where maintenance is considered a discrete 


maunction. 












aN MODE 


= 


VALIDATION 


A mathematical development of the Green/Selby model was 
completed by the authors of this thesis solely by algebraic 
substitution and reducticn, working with the basic equations 
and relationships from the works of Norden and Putnan. An 
empirical development of the model was completed using the 
Same cr similar data to that used by Green and Selby. Both 
developments follow. 


A. MATHEMATICAL DEVELOPMENT 


The Norden/Rayleigh curve equation, as discussed 


eeetier, is: 


2 


- 3+ 


Y' = 2Kate .« (4.1) 


This equation is characterized as a two parameter equation, 
as the outcome hinges on two parameters, K and a, calculated 
across the life cycle for all/fany times from t_ tot. 

The parameter, a, as used in the Green/Selby Model, is 


Calculated by: 


2 
ae, AS 2S “ue2 
a ( ) 


The Green/Selby Model appears to have been develoved for 
large projects with the assumption ‘that <¢ and = do 
* ® e « « Vv 
Meme tae. Therefore, if a is substituted into the 


Norden/Rayl¢eigh equation, the commonly used forn is found: 


Bye 





242 
-1/2t_ %t 


Z 
Y' = 2s ete a : 
which reduces to 
Z 2 
2 -t /2t 
Y' = SAS 7ERO d . (4.3) 


Norden noticed that the inflection point on the project 


life cycle curve is characterized by: 


72 
te f= (3/2a) . (4.4) 
ip 


If the equation for a is substituted in equation (4.4), +. 
i 


reduces to: 


: iW We 
t = (3/2/2%_ } = (3+) : (4.5) 
ip d 


Substituting this equation into equation (4.3) gives: 


2 Zz 
2 -((1/2t : 
Y! = 2K({1/2t_ )*t. @ ui dq y Bigs. ” ; 
co d ae) 
+0 
which reduces £9 
iz 2 yao Noy oe : Sie - 
Yy? =e k(a7oe. ) (3%. ) > uC d a “a ; 
3 d d 
+P 
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which further reduces to 


ro = 1,73K/t 80 (4.6) 
fe | 
1p 

In the Green/Selby Model, it is theorized that the 
meelection point of the life cycle curve and the point of 
nu on the curve for the maintenance phase coincide. The 
times t+ gandt are the same absolute time; however, for 
pur poses of Selene Gasp they differ, since t , the maxinun 
manning for the maintenance curve is calculated relative to 
the start time for maintenance or the t for the maintenance 
curve. If devslopment time is equal to t_, as was assumed in 
the Green/Selby Model, and if the maintenance effort starts 
at t , then the ee for the maintenance curve is + for «he 
life cycle curve. Figure (4.1), with a corresponding time 
line, demonstrates the general relationship. 


Green and Selby symbolized the elansed ‘time 7 to t as 
m 


iD 


t =t -t. (4.7) 


Memes at this juncture that difficulty in the develop- 
ment arises. The difficuity lies in the definition of where 
the maintenance phase begins. Does it begin at ee when the 
develcopment phase ends 2S in Pigure (4.1), or does z* begin 
sometime after that? The time to Y! _and thus, the shape 
parameter, a, depend on that aEama Some Green and Selby, 
uSing Army Data, stated that, on the average, the mainte- 
Nance phase béegan a*+ time 1.3 with ¢ Memmalaged £0 1 OF 
time jam + Ho Se Therefore, the 2stimate of + for mainte- 
Memce Curve projection, or +t, will be as shown in Figure 


3 
(4.2) and equation (4.8) below. 
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Figure 4.1 Maintenance Phase Tinaing Relationships 


The estimate of K for *he maintenance phase also cane 
Beem the Acmy data which indicated that, on the average, «he 
K for the maintenance phase is 20 parcent of lifecycle K or 


eek (litecycle) with lifecycle K nornalized to 1. 
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Figure 4.2 Maintenance Phase Timing Relationships in 
the Green/Selby Model 


Since it is theorized «hat + =t , it can be seen fron 
m 
meoucte (4.2) that 


Se wee eo. 5%.) , (4.8) 
SI 
It must be noted here that this development, because cf 
moe mature of the problen and the lack of firm data, cannot 


be a pure mathematical development; however, she attempt is 
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made to approximate it as closely as possible. Even «hough 
mre t , or time of Y* , in the equations for the life 
Bele. and maintenance. curves denote the same type 
relationship within their parent equation, the quantities 
are necessarily different. As far as the authors know, and 
it is projected that the case was the same for Green and 
Selby, no specific relationship between t_ (lc) and Wt 
have been found empirically. Therefore, for this development 
to exhibit credibility, known estimation factors from the 
Army data must be introduced. This also tends to indicate 
that until some firm relationship between +t 's is found, 
general applicability will be lacking. The same applies for 
the K factor. 

After substituting the value for t, from equation 
(4.5), equation (4.8) becomes: a 


; 1/2 
eo a=. (3 = (> ee os 3st = 0.43t . 4.9 
‘ ( 4 ) ( 3 a) 4 ( ) 
Substituting the value for ¢ (maintenance phase an into 
4 
eeeation (3.4) for the Y' of a curve gives: 
ma x 
-1/2 
bay = K/t fe, 
c 2 
m 
which reduces to 
-1/2 
Y' = 5 ACen eet ; (4.10) 
+ a 
n 


mee constant e(-3/2), in equation (4.6), is calculated to be 
0.223, and the constant 2(-1/2) above is calculated +o be 
0.507. They are substituted into equation (4.6) and (4.10) 
respectively to give: 


es = ea eee 2 OG 
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Y! = 0.38 6K/t Coan 


ce 
af 
and P 
x4 = 0.2K/0.43+ 70.607 Or 
e d 
m 
Ye = 0. HAVE Ue She oe (4.12) 
“tm 
Attempting to equate yt to an produces: 
dais: n 
0.386K Oat 2 1k 
-------- So eee enn ee we teeter (4.13) 
Be Oe ee 


Algebraic reduction carries the development to completion: 


one O0.121K 
oes ee ee rs and 
= 0.386K 
d 
0.43 = 0.121/0.386 (4.18%) 


which gives 


0. 43#0.313. 

A similar development using K's and 2.5 alone without the 
relational factors taken from Army project experience gives 
Similar results. This is significant since it indicates 
that, for large projects where life cycle - 2 - ee 
Manloading at the maximum point on the maintenance Snere is 
not necessarily equal to the manloading at the inflection 
point on the life cycle curve. There are situations where, 
Sreeretically, with the right values for ae Tang. = Vora Wo 
mee, ©  #éand ae Wail be equal, but it becomes apparent 
n 


iD 
that no such general rule can be demonstrated. Therefore 


=. 


Maes Ercoft of applicability, as has been the case in al 


+ 





areas of software cost eStimating research so far, falls 
back into the arena of empirical development. The empirical 
development used by Green/Selby follows in section B. 


Bae EMPIRICAL DEVELOPMENT 


The present authors, in recreation of the Green/Selby 


model, developed it as follows. 
All parameters were normalized to values of oe and K 


equal tcl. With + = 1 and equation (4.2) calculate a: 
2 
a = ey =O. D's (4. 15) 
Substitute a into equation (4.4) and calculate * :; 
+p 
1/2 
+ = (3/28) = 1.73 years. (4. 16) 
2D 
eapstitute ¢ into equation (4.6) to calculate Y' : 
ip < 
ip 
2 
ee 
iy? = 2Kat.e =D , and 
ie LD 
ip 
2 
Y' 2(1) (0.5) (1 Tey ee d 
= ) @ as — an 
1.73 ‘ 
: = 0.387 manyeatrs. Get? 
ies : 


To equate maximum maintenance nanloading to the life cycle 
anflecticn point, define the tine of maximum maintenance 


ee- . Thus, 
m 


Y' Vi) (4. 18} 


~ 
w 


ct 


sep m 
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U.S. Army Computer Systems Command project data indicated 
that, across the spectrum of Army software projects, «he 
Maintenance phase incinuded about 20 percent of the life- 
cycle. Therefore, K for the maintenance phase is 0.2K with 
respect to the normalized life cycle K value of 1. Here, it 
must be assumed that Army data analysis is valid. However, 
it is the contention of the authors of this thesis that an 
average of all Army large scale software projects will give 
a good figure for k/t FOr their types of projects. Arny 
data alsc indicated that the maintenance phase started at 


1.3 years normalized time Sen ifte Je - ae at cae 
then, making the same assumption as Green/Selby, that 
t =t, the time of maximum maintenance manloading , t , 
cah be calculated Dy: “ 
. = o = 6! and 
1.73 - 1.3 = 0.43 years. (4.19) 


Calculate a for the maintenance curve from equation (4.2): 
m 


2 
a = 1/2t = 2.71. (4. 20) 
m 2 
mess icute a and t into equation (4.1) to calculate Yv* : 
e t 
mn 
2 
=o alc 
x! = 2ka té a. 2 M ; 
ie me 
m 
2 
ue elit Oc ))) 
‘a =e iWeeKh) (2691) (0-83) 6 Be eT 
Om 
an. =0.22524. (4.21) 
m 
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Use equation (4.4) to calculate t. 
im 


1/2 
cee = (3/2a) = 0.74 years. (4.22) 
in 


The maintenance curve inflection point, *+. , on a life 


im 
cycle basis, normalizes to 2.04 years. Substitute t into 
im 
equation (4.6) to calculate Y' : 
im 
2 
(oe) ) 
vey = 2Ka te m im ; 
t. m im 
im 
2 
-(2.71) (9.74 ) 
7° = 2(0. 2K) (2.71) (0.74)¢ pee a 
“im 
a =O 26 (4.23) 
“in 


The normalized curve as developed above is depicted in 
Beagure (4.3). 
Here, ee is clearly not equal to Y' _, as was also 
ip em 
found in the mathematical development, bu* rather, y*' is 
m 
about 25 percent less than Y' | in nagnitude, when + and 
, ae tLp o 
= ccincide. 
1p 


Meee CAOAPTER FOUR SUMMARY 


In both the mathematical development and the empirical 
development, maximum manloading for the maintenance phase 
Sena manicading at the inflection point of the life cycle 
curve were not found to be equal. However, the maintenance 

2 


Maximum was below the magnitude at the inflection point. 
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Figure 4.3 Developed Norsmalized Curve 


Therefore, though the Green/Selby theory, in itself, nay not 
be substantiated, some relationship/s may exist which can be 
used for maintenance manpower estimates. The key relation- 
Ships in any maintenance manloading 2zstimates apvear to be 

those of life cycle K versus maintenance K and life cycle + 
versus maintenance t . If some empirical relationship (such 
eee cor all large Becjechs maintenance * is X percent of 
Wife cycle + or maintenance K is X percent of Pie sey els. kK} 
can be determined, then a nodel develcpment could possibly 
be completed which produces fairly accurate nanloading esti- 


Mates. Such a nodel would not necessarily 


aaa hinge on Y' |. = 
- 2, =P 
oa Peaesa-ner SOmNe Erelationship such as that exhibited dy 
ce 
~ m 
Syerali Arny projec data where Yr' Or maximum average 
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maintenance level fell at about 75 percent of ea The 
difficulties encountered in attempting «to develop the «hseory 
mathematically, in respect +o ifferences in K's and t_'s, 
suggest that there may be other factors affecting the 
relationshins and the parameters that determine those 


relationships. Such factors are discussed in Chapter VI. 
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Aw DATA DEFINITION 


The data utilized in the research effort was received 
fron two sources, NASA Goddard Space Flight Center, 
Greenbelt, Md., and Dr. Willa Ehriich, Bankers Trust Co., 
NY., NY. Both sets of data consisted of manloading for soft- 
ware projects over the life cycle and included maintenance 
data. Manpower utilization figures were in manhours for the 
NASA data and manmonths/mth for the Bankers Trust data. The 
NASA data was converted to manmonths/mth prior to analysis. 
The projects analyzed will be called NASA project and 
Projects A-D for the purposes of this thesis. 


Projects A-D were all medium sized projects, devel- 
oped at Bankers Trust Company. The few oroject character- 
jmeetes that were known can be found in Table V. A listing o£ 


project data by manmonths/mth is found in Appendix Cc. 


NASA project data were related to an operational 
System and, though it 1S an ongoing project and the complete 
Meee cycle is not yet known, much information could he 
Synthesized ‘from the life cycle and maintenance data to 
Game, Pertinent project characteristics are listed in Table 
Wal I* is readily 


BSppesenewe Nes eae —Projec= started as a 
Small project, ut that e 


it has migrated via maintenance to 


what could be cailed a large project. However, based on 
project size at the end of development, it must be classi- 
fied as a small sized project. A listing of project data by 


memmonchs/mth is found in Appendix Cc. 
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PARES ¥ 


Bankers Trust Cow. Projects Characteristics 











—— ee —————— 
| Project Name Size Development Maintenance Ending | 
7 A Medium 8/78 1/80 12/80 
| B Mediun 8/79 6/80 4/81 | 
| C Mediun 12/76 4/78 12/78 { 
| D Medium 3/77 11/77 12/79 | 
- a an _ 


Be ANALYSIS PROCESS 


The analysis process fell into «wo categories, curve 
B2eting, and comparison. Actual life cycle manmonth figures 
for individual projects were fitted against the Rayleigh 
equation via the facilities provided for non-linear curve 
fitting in the Statistical Analysis System (SAS) vackage 
available on the resident IBM 3033AP Computer System. The 
Marquardt method was chosen as the regression technique. [In 
addition, data from the four Bankers Trust Co. prejects were 
combined by normalizing * (the tim2® to reach Y' eu C Cum 
men Gach project and then the curve fitting techniques were 
applied to ‘the normalized/combined data. Manpower figures 
for the maintenance phases of individual projects and the 
combined data wer2 also fitted to the Rayleigh equation and 
Mien, in @ach situation, actual data points and fitted 
curves for life cycle and maintenance phases were replotted 
On a common axis to provide an aggregate picture of the 
phase relationships. 

The USACSC data was also reanalyzed. Though i+ did not 
BaoVide substantiation for the specific theory of Green and 


heeDy, aS noted in chapter four, i* does provide valuable 
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TABLE VI 


NASA Project Data Characteristics 


PROde GL bo non. 


Design start date 
Maintenance start date 


Date of last data 


CODE SHIsT ORY 


Lines of Code 


1. Original lines of code 
Ze 
a2 
4. 


Modules 


1. Original modules 
Ds 
Bi 
q. 


Modified lines of code 
New lines of code 


Total lines of code 


Modified nodules 
New modules 
Total modules 


pDocumentaticn 


Pages 


into the phase trtelationships 


A mass of raew data was 


taking the aggrecate figuras provided, 


the Rayleigh curve were calculated. 


After the curve fitting 


a, and 


Meintenrance curves 
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econ the life 
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cycle curves 
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were compared to 
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was completed, 





1975 
1977 
1982 


March 1, 
TUL 30, 
Janveny 25, 


Te eS oe 8 eee 


ern ene | 


4,000 
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Telatiorships. Curve magnitudes at t for the life cycle 
ip 
and Y° (t_) for the maintenance curve were also compared 
max 
in terms of the general relationships proposed by Green and 


Selby. 


fee ANALYSIS RESULTS 


An excellent fit was obtained for the life cycle curves 
for all five individual projects in relation to the Rayleigh 
model. From Table VII, correlation coefficients ranged from 
meme 0.776, for the NASA project, tec re = 0.966, fer Project 
A. The curve fit for the combined Bankers Trust projects 
obtained an r2 = 0.869. However, maintenance curves, in 
general, did not fit the Rayleigh model well, with correla~ 
fon coefficients ranging from r@ = 0.118 for NASA data to 
eee—- 0.762 for Project B. Projects B andD maintenance 
curves best fit the Rayleigh model with r@ = 0.762 and 0.747 
respectively. These findings indicate that the maintenance 
efforts are somewhat erratic, as alluded to in the GAO 
study, and, therefore, dio not fit a specific curves well. 
When maintenance is not managed as a discrete function, 
manloading peaks and drops in an inconsistent manner. This 
normally results as managers respond, on a crisis basis, ‘to 
provide maintenance activity only when trouble arises. 

In the NASA data, however, though the overall mainte- 
NMance data does not fit the Rayleigh curve well, visual 
inspection cf the curve reveals what apvear +o be a seri 
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whic 
manloading across th 


(D 
xs UW 


Seeesfalil Rayleigh-like curves, the combination of 


j~ 


Senmabit an overall rise of naintenan e 


Maes trend fits well with the proj Ghasdictesistice which 


ce 
&4vailable data, as can be seen in Figure (5.1). 
ject 
a mown =on 4U00 SLOC 


oem =nax the size of the project has 
Memancut 73,00C SLOC during its life cycle to date. lie 
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stands to reason that the "mini-development cycles" for 
those modifications/enhancements which created the increase 
in system size would, themselves, exhibit a Rayleigh 
Pattern, but the aggregate maintenance phase would not 
necessarily follow the same pattern. The aggregate curves 
are included in Appendix C. 

Comparison of parameters gave varying results, as can be 
seen in Table VII. Ratios of life cycle K's to maintenance 
K's ranged from 0.148 to 1.24 and ratios of life cycle eae 
and maintenance +t ‘ts ranged from 0.625 to 2.32. This seems 
#o indicate that no general relationship can be derived 
which relates K's and t_‘s for the maintenance phase versus 
the life cycle with Been sct Eo 2ndevidteal projects. However, 
as more data is accumulated and research efforts continue 
those relationships might be found to exist for various 


aggrega*e projects. 


when ae Sepere Mhdsyraduat f1tted lite cycle curves 
ci ; : 
WaS compared to Y’ Gt  th= 2hdividual fEitted naintenance 
- 
Em 
Suceves, Ssimiiar results to tho 


$3755 covered 2 wi 


di a 
Seve baae ned fOr K-and ¢t 
comparisons were observed. The =a a D 

Dp 


2 M. However, when the comparison was made for thea 
combined Sankers Trust orojects urves, the result 
Peeaningly similar to those 9 the NASA project and ths 


USACSC data. OSACSC data indicated, as shown in Chapter IV, 


that, on the average, Y' z => Descent = Of oe - Comparison 
Of actual maxinum manloading for the ponbinedeear n<ers Trus- 
Meegec. data to the ianflection point on the fitted life 
cycle curve gave oe = 69.6 percent of ET och teud (ron y 
one project, instead of an aggregate, the NASA data also 
Showed 2 mae Dele os Of hf = 59 peresnt of Y*  . 
mec the NASA Soo JSex, pares = bee A? ball Bor. weno pn may 7 Be 


= fe) 
guestionabl¢e, since some data points lay above the 69 
© 


Meeeaeoe Of Y' ievei. In fact, one od 





TABLE VIT 


Compilation of Analysis Results 





| Life Cycle Parameters | 


i ee re ee ale i i cee ae a —e 


iy ie ee A El TR a 


ae 


ep 4 4p 42 4a ee 2 Eee Oe ee ee ee eee eee ee eee ee Oe ee ee ee ee eee eee ee ee ee eee eee ee ee ee So { 
s 
® 
=> 


NASA Project .003969 11 28.410 1.54 0.9982 19.441 

Project A .007143 8 183.374 13.27 8.8586 14.491 

Project B MOMs 2Ium Got simetouNd6.06 8.8422 10. 25] 

Project C 007605 8 186.913 13.98 9.0296 14.044 

Project D .024288 5 81.383 10.77 6.2905 7.86} 
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However, if one accepts the theory that the NASA project is 
characterized during the maintenance phase by a _ series of 
"mini-development phases", then the points above the 69 
percent level can be interpreted as manning levels intrinsic 
+o the development effort and not characteristic of a4 
general maintenance program. Then the aggregated maximum 


Maintenance level lies at 69 percent of a 4 
ip 


D. CHAPTER FIVE SUMMARY 


The data were analyzed using non-linear curve fit+ing 
technigues to provide lif¢ cycle versus maintenace phase 
relationship comparisons. The results seem to exhibit inde- 
pendence of behavior with respect +o values of K and?t.. 
However, a general trend, within the limited scope of data 
available, was founcd which appears to point to a possible 
relationship between maintenance manloading levels and the 
Magnitude of the inflection point on the life cycle curve. 
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We 








ae = LNTRODUCTION 


The history of the software industry has been marked by 
cost overruns, late déliveries, poor reliability and mainte- 
mance, and user dissatisfaction. While these problems are 
not unique to computing, the record seems to indicate that 
software developers as a group are less successful in 
meeting quality, cost, and schedule objectives than their 
hardware counterparts.{34] With this in mind, a number of 
models have been developed, as discussed in Chapter IT, to 
provide management the necessary tools to more accurately 
predict the actual costs and time frames for their software 
projects. This thesis attempted to expand the work done by 
Green and Selby on Putnam's mcedel, with special emphasis on 
the maintenance phase of the software life cycle. Tiss 
included a detailed comparison of the peak manloading for 
the maintenance phase with the inflection point on “he total 


life cycle Rayleigh curve. 


Eee CONCLUSIONS 


The software project manpewer macre-estimating model, as 
presented by Green and Seiby, is not a usable model for the 
t20 2pwGrapte> TV, and 
+ 


project manager. AS was demonstra 
again in the data analysis in Chap? 


V, the maximum point 
on the maintenance curve is net necessarily 2qual to the 
meee cuce at the inflection point o Rewer e cycle curve, 
Bneugh, theoretically, it is pessib Peemewe, DOs neSs £0 
Mespedual. It was also found «hat th te point in time 

e 


u 
ef ‘the maximum maintenance manloading and the an Sect Ton 
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point may coincide, but, usually, will not. However, these 
findings dco not invalidate the basic ideas from which the 
Green/Selby model were developed. Those basic ideas were 
that a relationship may exist whereby maintenance manpower 
could be projected by comparison of the maintenance phase 
and life cycle Rayleigh curves, or derivations thereof. It 
was shown that, within the scope of the limited available 
data, only two of the five projects analyzed were character- 
ized by maintenance phases which closely fit the Rayleigh 
model. dowever, it was demonstrated that, for combined 
project data, within project type, and within a specific 
organizetion, a relationship does appear to exist between 
the maximum maintenance manpower utilization level and the 
inflection point of the life cycle curve, whether the main- 
tenance phase fits the Rayleigh model or not. 

In both the USACSC and combined Bankers Trust Co. data 
analyses, and with interpretive license in the NASA data 
analysis, maximum maintenance levels were within 65 vercent 
me /> percent of the level of Y' . O° There is not enough 
evidence here to show that there Shige a general rule that 
Maximum maintenance will be about 79 percent cf the magni- 
meae at the life cycle curve inflection point, but the 
implications for project managers within individual organi- 
zations are encouraginga. The results of the data analysis 
memear tO indicate that, for project type, within an indi- 
vidual organization, analysis of historical data and compar- 
ison of maintenance levels to life cycle curve inflection 
points will provide a general baseline maximum maintenance 
support level which the nanager can use in outyear mainte- 
Hance manning projections for future projects. For example, 
memitstOrical data for accounting type projects in organiza- 
tion X shows tha+ maximum maintenance manning is 65 vercent 


Be sche magnitude at the life cycle curve inflection point, 
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then the manager can apply that percentage tc the projected 
life cycle curve calculations for future projects to obtain 
a maintenance supvort projection at the inception of the 
project. As the life cycle curve is refined during the 
development phase, the maintenance level projections can be 
successively refined. This would provide the ADP manager 
with a valuable tool in an environment presently character- 
ized by a general lack of planning and management direction, 
in the area of software maintenance. 

The results of the data analysis further indicate, by 
Meat lack of strong correlation, that there are other 
factors which may have a strong effect on the level of main- 
tenance required for any software systen. Thies finding is 
not entirely surprising, as the authors of this thesis, 
after extensive readings in the literature, did not have 
much confidence in the possibility of discovering a single, 
general, Simple decision rule for software maintenance 
Manning. Rather, the research completed here is only a tiny 
bite taken from the mountain of research which needs to be 
done. The possible set of constraints and combinations 
therecf which affect the software process is astounding. A 
few were highlighted by this research effort. I+ was found 
that there was no firm relationship between K's and S78 ‘apg 
the corresponding life cycle and maintenance phase curves. 
SiS cota l Lats 


cycle manning) are attributed to such factors as project 


It can be hypothesized that difference 


#7) 


Eeee, complexity, and project type. It follows that larger 
projects wili require higher overall manning levels than 
SMailer sized projects. The relationships of maintenance +t 


Meesis ilif2e cycle ¢t desman “eGeet oan large dart, bd 


bag py 


Semelexity and size of the project. Differing systen 
complexities may place heavier burdens on different ovhases 
u te 


or the development processes, and, thus, ca (time of 
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maximum manning) to occur at different times for different 
projects. There may be, and the authors of this thesis feel 
that there will be, no definable relationship between the 
point of maximum manning for the maintenance ovohase and the 
corresponding td for the life cycle. Since only two of the 
five projects analyzed actually fit the Rayleigh model for 
the maintenance phase, it would appear that for some 
projects, a definable ee would be forever elusive. Only in 
those projects where some type of "mini-development" effort 
is completed in the process of providing enhancements or 
major modifications will a good fit to the Rayleigh model be 
realized, accompanied by a definable maintenance i versus 
mee cycle t relationship for that project. 

A Penstraant of even greater importance is the use of 
varying software development techniques and methodologies. 
It has been speculated that the majority cf research to date 
has been conducted with data collected from projects which 
were characterized by design and coding efforts which did 
not include structured, modular-design techniques, informa- 
tion-hiding modules, and other software development concepts 
and tcols. These projects have shown a very close relation- 
Ship with the Rayleigh model. A tremendous impact on the 
entire arena may be seen with the increased use of the above 
listed design techniques. How these techniques will affect 
the software equation and, in particular, software nainte- 
mance, is yet to be seen. 

The rise in maintenance activity for «he NASA project, 
as new develooments apparently added modules and scurce 
lines of code to the system, seems *o support the results 
obtained by Lehman and Belady, a5paescz2 eed in Chaoter II, 
that, as enhancements are added to th? oridqinal project, the 
maintenance level reguired to supoort the project also 


Mises. This could be attributed to the fact that <*he 
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additicn of enhancements adds complexity to the system 
which, in turn, causes a resultant increase in the mainte- 
mance level required. As was discussed earlier, and as is 
seen in the NASA project data, if enhancements continue, the 
maintenance manning rises above the magnitude of the inflec- 
mon pOint on the life cycle curve. This could also indi- 
cate that «he point in time at which the project should be 
totally rewritten and restructured as a new project has been 
reached, and any further development-like effort on the 


System should constitute the inception of a new project. 


C. RECOMMENDATIONS 


One of the most difficult problems encountered in «he 
preparation of this thesi was locating organizations which 
had compiled and/or retained historical data from their 
software development and maintenance efforts. Some or the 
organizations contacted had maintained some form of histor- 
ical data, but they had not broken their information down 
into a format which could be used to obtain information 
about the separate phases of the software life cycle. 
Therefore, if any meaningful research is to be conducted in 
the future in this area, organizations which are responsible 
for producing or maintaining software products need to start 
accounting properly for the various costs associated with 
this process. Proper accounting includes, not onlv tracking 
the number of source lines of cod produced for the project, 
but total man-hours expended in each phase, «he actual time 
frame for each phase, and the applicable complexity factors. 
The coliection of this data, however, must be an ongoing 
process, just aS 1S proper documentation of software, and it 
Should become a part of ‘+his documentation. By making the 
collection process an ongoing process, *+he data is always 


current, and less subject to error. For, like any other 
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form of documentation, if postponed until the end of the 
project, it is subject to a host of errors, omissions, and 
inaccuracies. However, even if the collection process is 
done with total perfection, it means nothing unless the data 
is recorded in such a manner that it can be retrieved and 
understood easily. It is therefore recommended that this 
data be stored in an automated data file so that 1+ can be 
accessed quickly and analyzed with greater ease and effi- 
ciency than with a manual systen. With the cost of software 
rising at an ever increasing rats, the benefits of this 
information to the organization, seem obvious. Not only 
should it be better able tc predict future software manning 
requirements, but also, it should be able to identify and 
correct other inefficiencies within the development and 
maintenance processes. 

As noted by GAO, andas indicated by the NASA data, a 
generally accepted but uniform definition of software nain- 
tenance is not now in existence in the majority of organiza- 
Pons « In addition, management is not presently requiring 
that software maintenace be managed as a discrete function. 
This leads +o many problems for management at various levels 
Sethe organization. AS such, it is recommended that the 
definiticn proposed by GAO be adopted as the uniform defini- 

ton of software maintenance. I+ also 1S recommended that 
software maintenance be accomplished as a discrete function 
Within the organization. The adoption of the GAO definition 
will leave a gre7 area where enhancements to the old project 
stop and anew project begins. However, if management 
formulates a project maintenance strategy which includes the 
development of a mnaintenanc2 support level, whether it is 
based on a percentage of the magnitude at the inflection 
point on the life cycle curve, or on some other nanagement- 


defined function, a point will exist above which management 
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should decide to terminate enhancements to that project and 
start a new project. This project would be developed as a 
follow-on to the old system. The old project should be 
terminated or continued with a minimum maintenance support 
level to effect necessary repairs until the new system comes 
online. 

Although there appears to be a strong correlation 
between peak maintenance manloading and a fixed percentage 
of the manloading at the inflection point of the total lifs 
cycle Rayleigh curve, Further work needs to be done to 
determine if this relationship holds true throughout the 
software industry. This work should include comparisons 
across all types of software and comparisons within ?2ach 
class to determine if there is a value that management could 
use as a planning tool for the type of software they are 
producing. Follow-on research to this thesis would b¢ most 
beneficial if completed in the following manner. A latger 
base of life cycle/maintenance data must be collected to 
provide a better picture of the relationships concerned and 
to obtain a higner percentage of validity in the findings. 
Projects need to be analyzed individually, grouped by 
project size, grouped by tvrpe of system involved, grouped by 
complexity factors (if Known), and grouped within specific 
Otganizations as well as a ~Ortte Combination Of the 
collected population. Research should be done to examine 
Peecential relationships of K's, t_'s, and a. versus Lae 
for the corresponding life cycle and naintenance curves. A 
particularly important area of research will be the effect 
of new software development techniques on the software equa- 
tion. Any data collected on projects which were developed in 
this manner should be segregated and analvzed separately. 
Mae potential for research in this area is unlimited in 


scope and in promise. 
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ANALYSIS OF SOFTWARE MODELS BY THIBOD 


tty 
{x 
ic 


A. INTRODUCTION 


Robert Thibodeau, whiie working for General Re 
Moeporaton, was contracted by the Air Porce to c 
study of the various models currently avalilable ¢£ 
ware cost estimation. This appendix consists of excerpts 


meeom his review. 


Be. AEROSPACE MODEL 


Description of the Model 

The model was developed using regression techniques 
applied to data from software development projects charac- 
terized by one-of-a kind computers, limited support soft- 
ware, software, special languages and severe memory size and 
speed requirements. The data were stratified into two 
groups. One group contained 13 projects for the development 
of real time software identified as primarily large-scale 
airborne and spac2 applications. The second group consisted 
of 7 operational support programs presumably without the 
size and speed requirements of the first group. 

The model description is net clear concerning the exact 
composition of the estimate of effort tegquired «+o develop 
the software. One yet ouccralmmetLorc 15 extimated. The 


estimate is made using a ralationship of the fora: 
MB =a (Tnstruction) 


whete the constants, a and b, ara determined by regression 


80 





0.404 
MM = 2.012 (T) 
where: 
MM = total development effort, manmonths 
I = number of instructions (independent of 


language). ... 


meee DOD MICRO ESTIMATING PROCEDURE 


Description of the Model 

The primary estimating relationship comprising the DoD 
Micro Procedure can be described as the ratio of a factor 
representing the software to be devsloped or changed and a 
productivity measure. 

The model form suggests that sffort increases directly 
with the number of input and output configurations operating 
on the system being built. Effort also increases with the 
number of routines being created or modified weighted bv 
mete difficulty. Tne total effort is scaled according to 
the amount cf work that must be done in entirety as opposed 
to modification of an existing systen. 

The number of days neaded to deliver the vroduct (effec- 
Sawely the Gays of effort per unit of product) depends on 
the general experience and accomplishment of the development 
group (measured by their job classificaticns) weighted by 
their knewledge of the problem to be solved relative +o the 
knowledge required. Gne- S2h=— facts: that direc a 
she productivity is the ease of access +o the computer 


(measured by turnazound time). 
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the kasic form of the estimating relation for software 
development time is: 
Net Development Time = (Product) / (Productivity) 
Where: 
Product is a measure describing the effort to be per- 
formed. 
Productivity is the rate of creating the product from 


the applicaticn of personnel tine. 


Product = (Number of Formats + Weighted Number of 
mine Lens) xX {(EEESrc Relative toa New 

Deve lopment) 
The terms in parentheses along with the following terms 


are defined in the discussion of model inputs below: 


Peeductivity) = (Work Days per Unit of Product for a 
Staff with Average Experience) 
x (Job Knowledge Required) 
x (Job Knowledge Availabls) 
x (Access) 
The result is the total hours required for code develop- 
ment. Presumably «his means detailed design, coding, and 


mot testing. 


Gross Development Time = (Net Development Time) 
x (Other System Factor) 
Mr NON notre cee Factor + Lost 


Time Factor) 


A value of 1.8 is recommended for the other systen 
Pactoz=. This factor represents the effort needed to convert 
she cede development time to total dsvelooment tine. This 


value is representative of an observed range from 1.2 to 


Ze1. Total development includes analysis, design, coding, 


testing and documentation. Paavo seesum Of the project 
Mezect charges. Whether this includes support hours for 
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elerical and other functions is not clear. but any given 
organization could include these by modifying the 1.8 
factor. 

The net development time accounts for the time Lost from 
normal scheduled working hours for leave, sickness, holi- 
days, and non-project assignments. These add 25 percent +*9 
the total development time. There is also a 10 percent 
efficiency factor (coffee breaks, time cards, code rework, 
ec.) « The code rework should probably be handled else- 
where. It is probably included where it is to make the 10 
percent palatable. It should be included in the gross size 
adjustment and the 1.8 factor. 

The effect of these adjustments is to estimate the 
number of personnel who must be assigned to the project to 
ensure delivery of the total dev2lopment hours. These 
ae-Ors are orgainizational specific. 

Although the resource estimating procedure includes 
weighting factors for the input and output formats by type 
of device (see subsequent discussion), the factors have a 
value of one in each case. Therefors, the model describes a 
linear relationship between the total number of file formats 
and the effort required to implement then. iy May be thac 
future versions of the model will weight the types of file 
device differently. Then the effort required to implement a 
report format may be different from the effort required for 
aecard format. 


Program complexity, which 15 the second term in th 


WD 


product measure, is the weighted sum of the functions to b 


iD 


implemented. The weights depend on the functicrn and its 
@ssumed level of complexity. The weigh«=s rance from 1 for a 
Simple operating system control language change to 12 for a 


Memy complex edit-validation function. 





The value 3 is the most common among the 24 possible 
functicn-complexity assignments. I€ the function types are 
equally represented in programs, the average value is 4. 

The programmer/fanalyst experience factor is an indica- 
tion of the effect of experience on productivity. Values 
range frem .75 to 2.75 corresponding to atlead analyst to 
programmer and interns respectively. Since experience is 
not evenly distributed over a group of programmers and 
analysts, the following groups was hypothesized in order to 


obtain an averaqe or representative value for the experience 





mac ctor. 

Number Weighted 
Experience in Group Factor Sum 
lead 1 ES ato 
Senior 2 1225 2250 
Journeyman Uy 7S 700 
Nominal 8 Za RS 00 
Intern 5 2245 To S 

20 42.00 


Average Value = 42 / 20 = 2.1 

emoecticicti0onsS are provided for the 10 job classifica- 
Eons. The job knowledge and turn-around time factors are 
self-explanatory. 

The System Factor adjusts the product development effort 
Pes ecccunt for work already done. The product measure 
resulting from the fermat count and the program complexity 
Value is the same whether the systen is being developed in 
mes eCntiret 


Ol smc NOd™ticat2On £O an existing systen. 


fo) 
Meemmovystsm factor has the effect of modifying the producs 
us D 


value to account for less than total development. 
Seven levels of change are described by the System 
mactOL. The values range from 2 for a new develooment +0 8 


Vv 
for an operating systems control language change. 
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For a new system development the 2 in the primary esti- 
mating eguation is divided by a Syst2m Factor value of 2 and 
the product measure is unchanged. Consequently, the System 
Factor values describing lesser amounts of new development 
have larger values and are portions of 2. The effect of the 
System Factor on the product measure is summarized as 
follows; 


BLrkort Relarcive £0 
myoe of Effort System Factor a New Development 











New Development 2 1.00 
Major Change 3 od 
Majer Modification 4 e0 
Maner Modification 5 49 
Maintenance 6 a3 
Minor Technical Change 7 Bara 
Operating Systems 

Contrel Language Chandgé¢ 8 wos 


In order to get a feel for the relative magnitudes of 
the compcnents of the Micro Estimating Procedure, consider 
the following example. 


Number of I/0 formats = 10 
Number of functions = 20 
Average complexity factor = 4. 


New Development 


Product (Number of Formats + Weighted Number of 
Functions) x (Effort Related to a New 
Development ) 

Product = (10 + 4 x 20) x 2/7 2 = 939 


Experience = 2. {See above for computation) 


Job knewledge required = 1.9 
Jop knowledge availiable = 1.9 
Access = =< pete 
Peecduc ivity) = (Work Days per Unit of Product for a 


Staff with Average Exverience) 
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(Job Knowledge Required) 
(Job Knowledge Available) 
(Access) 

pete \Va0ex1.0 xX 140 = 2.0 


x SM 


Net Development Time = (Product) x (Productivity) 
90 x 2.0 = 180 Man-Days 
If the effort was a major modification (System Factor = 


4), the Product value becomes: 
product = (10 + 4 x 20) x 274 = 45 
and 
Net Development Time = 45 x 2.0 = 90 Man-Days 
If the Job Knowledge Required is "Detailed" (Pactor = 
1.5) and the Job Knowledge Available is "Limited" (Factor = 


mon, and the productivity becomes: 


eesiuctivity). =o Veo & leo =X, 1aQ0 = 4.5 
then for the major modification: 

Net Development Effort = 45 x 4.5 = 202.5 Man-Days 
out puts 

The primary output (1.2@., the output that is sensitive 

or controlied by project variables as opposed to the subse- 
guent step which is a fixed allocation) 1s: Gross 
Development Time (man-1a ys}. Gross Development Tine 
includes: 

e Nonproject time (individual assigned to project but busy 
with nonproject tasks, e.g., training, nonproduct admin- 
Mmatmative duties, etc., and vacation and holidays) 

e Wasted or lost tine 

therefore, Gross Development Time describes the staffing 
level that wili result in a needed anoun of development 
mime. Benes fatter aS) predicced by program and project 


characteristics. 
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The secondary outputs (i.e, those derived by applying 

fixed values to the primary output are: 

e Effort by project phase 

e Total development cost 
The project phases are: 

e Review and analysis 

e Design 

e Programming 

e Testing 

e Documentation 
Gross Development Time includes: 

Analysis of present methods 

Design of the new/changed systen 

Develop the system's support 

Program design 

Program development 

Program testing 

System testing 

Installation and conversion 

Staff training 

Beeaject officer 

System manager 

Technical managers 

Support personnel 

Documentation 
Inputs 

Beoguc: Related Inputs. The sof S 

the numbers of ‘*ypes of items it orocesses and the numbers 
memecunctions it includes. The fu re described 
Meectca:ng to type and complexity. The result is two croduct 
descriptors: one measures the size 
processing to be execute by the syste¢ 
measure cf *he number and difficulty of the functions to be 


per forned. 





ts. The number of different formats to 
e system are counted and added together. The 
model asks or numbers of card, tape, disk, and screen 
formats separately, but since the weighting factor is always 
one, there is no distinction mad¢ among them regarding the 
effort involved to implement then. 

Output File Formats. The formats output by the systen 
are totaled. The same entries as for the inputs are 
requested plus the number of report formats. As in the case 


Seerhne inputs, the weighting factor for the different types 


of output is always one, so there is no reason (to 
differentiate. 
Program Complexity. The total program complexity 


measure is computed by a weighted sum of the number of 
processing functions of given types. Each function is char- 
acterized as sinple, complex, or very complex. The 
processing functions are: 

e Edit Validation 

® Table Look-Up (Internal or External) 

SeCalculations 

e Sort/Merge Process 

e Internal Data Manipulation 

e File Search 

Seo tiiizies or Subroutines 

° Operating Systems Control Language 

Job Knowledge Required. The amount of knowledgs 

required to implement or change a system has a direct 2ffect 
on the number or hours required to accomplish the project. 
A system that requires very detailed knowledge will requires 
more effort than one that can be accomplished with limited 
knowledge. This parameter is vaired with the job knowledge 
availabie factor described below ‘to describe the relative 
BEE uence on preductivicy. Three job knowledge levels are 


used: Limited, Generai, Detailed. 
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System Factor. The effort required to complete a system 
development or change project of given complexity depends on 
the state of the system. That is, the work required to 
develop a system with three file formats, all other factors 
being equal. The System Factor describes the level of 
effort being undertaken. Seven levels are described: 

e System development 
e Major changes 
e Major modification 
e Minor modification 
e Maintenance 
® Minor technical change 
® Operating systems control language 
Resource Related Inputs 
The available 


2ffective productivity indicator. 
+ 
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experience measure is at 
It quantifies the rate at which he product can be produced 
in terms £ the job classification of the staff available 
for assignment to the system development. Two data 
processing personnel elacs vEtesatvons: Analyst and 
Programmer, are tabulated according to five levels of expe- 
rience: tead, Senior, Journeyman, Nominal, and intern. 


Welghts are associated with the difference experience 


levels. The result is a weighted average productivity 
mae OL. 

Job Knowledge Available. Mts f£eacvor has the effect of 
describing the change in productivity associated with the 
level of knowledge about the work <+to be performed that 
exists among the persons available for assignment. I+ works 
together with the Job Knowledge Required ‘factor described 


above to quantify the effect of the knowledge of the systen 
required compared to that available on the cine required to 


complete the work. in general, the effect of the combined 
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factors is to increase the development manhours if the need 

exceeds the available and decrease the hours if the avail- 

able exceeds the need. Three levels of job knowledge avail- 

ability are specified: Limited, General, and Detailed. 
Program Turn-Around Time. The effect of computer access 

On productivity is described by four levels of average 

turn-around time: 

e Interactive terninal 


More than one run per day 


e One run per day 


Less than one run per day. 


D. DOTY ASSOCIATES, INC. 


Description of the Model 
The model is actually a set of 15 estimating relation- 
ships. Fach one to be used for a given type of software and 
software life cycle phase. Equations have been derived 
empirically using regression analysis for the following 
types of software: 
e Command and Control 
Seeceientific 
e Business 
Seutility 
The develooment effort for software representing 2ach of 
the application types may be estimated using one of three 
different relationships. An additional three are given that 
are applicable to all types of software. These equations 
are to be used "when ths application cannot be cateqorized 
Bees d2tferent chan the categories noted", The procedure 
svecifies that when a software system is made up of subsys- 
tems that are different types, the total size should be 
the four categories and the appropriate asti- 


O 
Mating equation used for each one. Then the individual 
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Manmonths are summed to give a total system develcpment 
Pecort. The three equations are divided into size measure 
(lines of source code or words of object instructions) and 
+he life cycle phase in which the estimate is made (Concept 
Formulation and all others). If the estimate is to be mad=2 
using the words of object instructions, the same equation is 
used in all life cycle phases. Similarly, for estimating 
large systems (more than 10,000 lines) using lines of source 
code requires the use of a different equation in the Concept 
Formulation Phase than in the other life cycle phases. 

The use of the different equations can be described as 
follows (Ay By, and ¢ refer to the three different 
relationships). 


SOFTWARE Rieu Cl.Cuae PoASE 
: DESCRIPTION | CONCEPT OTHERS 

a ! 
{| WORDS OF OBJECT CODE A | A | 
ee a -——-- ! 
LINES OF SOURCE CODE | | 
| LARGE SYSTEM > 10K LINES B | 
SMALL SYSTEM > 10K LINES | B Cc | 


ee 
The forms of the estimating relationships are similar. 





Equations A and 8 are of the forn: 


b 
44 sail 
where 
MM = Manmonths of davelopment esffort. 
I = either words of object code (A) Cm Lines SL 


executable source code (B). 
a, = Constants obtained emodirically. 
Equation C has the forn: 
1 


a 
mae = cr £2 i f£. 
cae) 


om 





f = a set of parameters describing the development 
: environment. 
c,d = constants obtained empirically.... 


The following guidelines are presented for selecting the 
proper estimating relationship. 

e In Concept Formulation, if the size of the program in 
object code is known, use the object code estimators. 
They will give more accurate estimates of manpower 
requirements. 

e If accurate estimates of manpower requirements are re- 
quired in the Analysis and Design and subsequent phases 
of development, use e2quation B, in source code, for 
programs of I 2 10,000 and equation C, in source code, 
Bese OLOGELams with I < 10,000. 

e For budgetary purposes, use the equation that gives the 
higher estimate. 


Development time is estimated using the equation 


1000Tf 
D = c37r3rrr ern erNKNK 
- 667 
92.25 + 233TI 
where 
D = Reasonable development time in aonths 
I = number of delivered object instructions. 


This relationship was obtained using reqression on data 
describing 74% developnment projects. The time estimate 
egoeu.d describe “customary" distributing of effort over tine 
that is, it should avoid extremes of proiect time compres- 
Sion cr Expansion. 

Mmeesnould be noted that a large portion of the documen- 
Mae2on accompanying the description of the DAI estimating 
Meoceaures :s devoted to discussions of factors «chat are 


pelieved to infiuence the cost of software development. 





These factors are classified according to aspects of soft- 
ware and its development environment. The factors are 
grouped according to the following "domains": 

e Reguirements 

e System Architecture/Engineering 

e Management 


The estimate of total development cost is based on 
several relationships that portion the cost into components 
that can be estimated by applying available ratios to other 
costs and factors such as overhead and administrative costs. 
By the proper use of relevant values for these factors «he 
relationships can represent either goverment in-house costs 
or contractor development costs. A method is described for 
time phasing the expenditure that is said to satisfy the 
requirements of DoD Directive 5900.1. 

The procedure identifies costs that are incurred by the 
government during all phases of the software life cycle 
except Operation and Support. The total develovment cost 
includes: 


CG =20 = a Si an © 
Cr VAL Poe 
where 
Cc = Development Cost 
c = Conceptual Phase Cost 
cr 
c = Validation Phase Cost 
VAL 
c = Full Scale Development Cost. 
ey 
Information is included *hat relates the governmen= cost 
memene CCntztactor's full scale development cost. oe SeGose 
is the one developed by the formal software cost estimating 


Bee cedure. 
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the cost of development is divided into primary and 
secondary costs, thus: 
Cie = (Ce C 
D P 


5 

where 

a = Cost of Development 

es = Primary Cost (Manpower) 

A = Secondary Cost (Computer, Documentation, Etc.) 

then, 
C = MM(C ) 
P e 

where 


MM = Total Development Man-Months 


C = Average Labor Cost 
e 
and 
n 
C= wc = kCc- 
Salta! 2 o) 
Therefore: C = (MM)C (1L+k) 
D 2 
where 


k = Ratio of Secondary to Primary Costs (=.075} 

The total software development cost (does not include 
government Conceptual and Validation Phase costs) includes 
eae costs of: 

e Analysis 


e Desian 


e Code 
» Code 
e Debug 


eeeeerest and Checkout 
and is poropertional to the *ctal man-months of development 
Ort. 


94 





Total Develcoment Man 








This is the primary output variable. It is the basis 
for the total development cost estimate and it is the value 
Seem Which the distribution of effort by life cycle phase is 
derived. The hours include those directly related to the 
development of the software system. They include the direct 
hours needed for: 

Analysis - interpreting the system requirements and 
producing viable aiternative system concepts 

Design ~- preparing detailed designs cf the data processing 
system and the individual programs 

Coding and Debugging - writing individual modules and 
programs and performing individual tests 

Testing and Checkout - integrating the individual subsys- 
tems into a complete system and conducting prescribed 
tests on the entire systen. 

The discussion of the model does not indicate the extent 
that support and management hours are included in the tot 
Also, there may be some question about the activities 
Clated with concept development {e.g., is the test plan 
furnished by the government following the validation phase 
or 1S it developed as part of the project). As in many cost 
estimating situations, the line between concept analysis and 
the evaluation of solutions to selected concepts is hazy. 

Although the DAI decumentation and discussions with the 
authors indicate that the model includes integrated system 
“esting, it appears that this effort is not included in the 
memoetid! SDC data which was the basis for the curve fits. 
(76% cf the SDC data points describe programs that do not 


interface with anv other vorograms). 
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A nominal development tine is presented that implies 
"customary manloading". Tides, “he schedule does not 
reflect either crash projects or allow for unnessary delays. 





Distribution of Development Effort 

The expenditure of time and effort associated with major 
project milestones is given for small projects (one level of 
Supervision) and large projects (more that one level of 
supervision). The distributions are for neminal projects 
and do not allow for any vossible acceleration oor delay of 
ene completion of the project.... 

Inputs 

DAI has been very carefull t95 describe the size vari- 
ables which are the primary inputs to the estimates using 
the relationships. However, we should pcint cut that the 
respondents to the original SDC questionnaire were not so 
well directed and it may be necessary when analyzing the 
structure of the model as it relates to prediction accuracy 
that significant errers may have been introduced by this 
failure to be specific. The DAI model may not overcome what 
are inherent limitaticns in the data. 

The DAI procedure calls for several estimates in support 
of the DSARC process. It reccoqnizes that the best estimates 
of program size are obtained later in the development cycle. 
It suggests, chen, that the interpretation of the progran 
size changes during the life cycle and that associated with 
the change are increases in estimating accuracy. The report 
describes how the knewledge of the size estinator changes 
during «he life cycle and how this affects th2 estimating 
precision. The precision associated with the different size 
measures during the system development life cycle is as 
mol lows. 


Cede that is developed as part of <“h 


(D 


DEOgecc. DU=. LS Ot 
@emryered to the customer isa source of variation in the 
estimate of the system size and must be considered. 


However, no guidance is orovided for making any adjustment 





other than citing that the SDC data showed delivered code to 
average 77 percent of the developed code with a standard 


error of 30 percent. 


SOFTWARE ESTIMATE WHEN SIZING BASIS Z% ERROR 
te INITIAL PFCGRAM CONCEPTUA 
SUOCETARY EST IMATE UAL PHASE TOTAL CBVJECT CCDE UP TO 20928 
@ A VALIDATION PRIOR 
VALICATICN COST TO RFP RELEASE DATA AREAS” le yes ees 
ESTIMATE 
3. INCEPENODEAT FSO COMPLETION OF TOTA 
COST ESTIMATE Syouem se ec RATA AREAS WITH He 
THROUGH POR ADJUSTMENTS FOR 
4. UPOATE OF FSO POR THRCUGH 
CCST ESTIMATE REMAINDER CF omen coe, CORE TePROVING 
DEVELOPMENT TC ZERO AT 
CCMPLETION 


pe eon epee eo ap ee oS SS > Se aw a eR a ee a Oe ee ee es ee a ee ee 
DE oe eer GS Se ee ane = ame 


*THE ACTUAL M£Y BE 200 PERCENT 
eee vey BE 206 ENT OF THE ESTIMATED OR THE ESTIMATED MAY BE 200 


Allowance nust also be made for support software devel- 
opment especially when working with new hardware. 
Total Object words 

During the Conceptual Phase when very little is known 
about the system to be developed, the initial estimate is 
made using the analyst's judgement (usually by analogy with 
previously developed systems, but other methods are 
possible) of the number 9° object words occupied by "ever 
program needed to run and maintain the system in the field". 
This measure is obtainable from listings of computer systen 
routines that build executable programs from the o 
the compiler. Taking values from systems Stuelas <0 the One 
being planned can provide a basis f5r astimating the valu 
Care should be taken, however, when program overlay 
involved. Also, extensive use of standard library routines 
can greatly increase the words of Sp ece  peojaan ~“sizZ 
not be representative of a comparable increase in develop- 


moms effort. 
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Total Object Words Minus Data Areas 

The memory space occupied by an executable program is 
composed of locations containing instructions and locations 
reserved for the data upon which the program will overate. 
Sometimes the data storage areas are significantly larger 
than the area occupied by the actual instructions. DAT 
suggests that the effort required to develop the programs is 
more closely related to the size of the instruction space 
than to the size of the combined data and instruction 
storage. However, as in the case of the total object words, 
there is no evidence of this distinction being made in the 
original derivation cf the estimating procedures. Also, 
there is no quidance provided on how to apoly the additional 
information when preparing cost estimates. Some computer 
System executive processing routines provide this inferma- 
me.ON. However, many don't and, therefore, i+ would be very 
feercult to obtain comparable historical information to 
guide new estimates. 


New Object Words Minus Date Ar: 


iD 
ip 


S 


omy “he woiting of new 


QO 


odé contributes *o the software 
development effort (1f code written to nodif ex 
modules is counted as new code). To account for the wo 
done to adapt existing code to a new System, which includes 
analyzing the code and deciding how tc modify i a 
€xisting module that will result is less than 50 percent 


Hemi za-20n of existing code is considered to be entirely 


Mew source iines written (whether in a higher 
order or machine oriented language} Can be obtained fron 
Semel ue> listings, measuring card decks or text editors. It 
is one of the easiest measures of size to obtain. As in the 
previcus case, modules containing less than 50 percent 


* 


reused code are considered to be new. 
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evelopment Environment 





For estimates made using lines of source code where the 
size is less than 10,000 lines, the estimating relationship 
includes anumber of factors describing the development 
environment. These are included in the estimate when the 
indicated item is to be part of the development process.... 

f1 Special Display 

£2 Detailed Definition of Operational Requirements 

f3 Change to Operational Requirements 

€4 Real Time Operation 

£5 cCpP0 Memory Constraint 

£6 CPU Time Constraint 

£7 First SW Developed on CE£&U 

F8 Concurrent Developed on CPU 

£9 Time Share Verus Batch Processing in Development 
£10 Developer Using Computer at Another Target Computer 
£11 Development at Operational Sits 

£12 Development Computer Different from Target Computer 
£13 Development at More than One Site 

£14 Programmer Access to Computer 

After analyzing the methed used by DAI <*t0 obtain their 
estimating relationships and after comparing “their defini- 
4i0ns of input and output variables with the original 
sources of data, 1t is clear that there are discrepancies 
between the way the data are peing applied and what they 
OTiginally represented. Died GesmenOtecxpDlic2ty Justiiy 
their approach but their presentation € the estimating 
procedure does give consideration to errors arising from 
differing definitions of the variables. 

DAI seems to be saying that consistent use o 
mating procedures regardless cf how they were obtai 
produce results with at léast a oredictab 5 


kKnoWing the range of error that can occur bec 


she, 





differences in definitions and ability to predict the input 
variables will, when applied to the given estimating rela- 
tionships, produce estimates with precision that is in 
accordance with previous experience. DAI further substanti- 
ates the approach of throwing all the error into the ability 
to define the input by presenting standard error values for 
the size variables at different times in the life cycle. 


Ee. FARR AND ZAGORSKI MODEL 


Description of the Model 

Systen Development Corporation completed several 
Beegects for the Air Force, Electronic Systens Division in 
which they attempted +o develop methods for predicting the 
cest of software development. The Farr and Zagorski model 
represent an intermediate stage in the program. 

Osing historical data from internal projects and fron 
other organizations, the SDC team systematically tested over 
100 variables to learn if they were satisfactory predictors 
of program design, coding and debugging effort. 

Farr and Zagorski published three squations which were 
determined to be the best predictors tested up to that *+ime. 

fee= 2.7X + 124K + 26K *€ 12K +%+#22K -— 497 (1) 

1 2 3 4 5 


em ok ete leok tf 33K = T/X + T0X. + X = 155 (2) 
6 7 3 8 a 19 


MM = 8.4X cath aod vem ke = 36 7 X - 42 (3) 
11 12 3 13 
Definiztson of Output 
MM is the naumber cf manmonths needed to design , code 
and debug a single progran. The effort begins when a 
programmer cr analyst is diven a complete operational speci- 
Mmeecl2ON fOr 2 program and it ends when the program is 


teleased for integrated system testing. 
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Definitions of Inputs 


X = number of instructions in original estimate (in 
thousands) 
X = subjective rating of information system complexity 
f (scale 1-5) 
Ss = number of document types delivered to customer 
a = number of decument types for internal use 
a = number of computer words needed to store program 
+ 
data OE) 
Sa = number of instructions in delivered program (in 
+housands) 
= = number of mun-miles for travel (in thousands) 
X = system programmer 2xperience (average of total years 
; cf experience with the computer, language, and 
application) 
Ss = number of display consoles 
40 = percent of instructions new to this program (not 
re-used from prevelics versions) 
coe = number of instructions to perform decision func- 
tions (in thousands) 
y = number of instructicns tc perfcrm nondecision 
functions {in thousands) 
1G = programner experience with this application (aver- 


age number of years). 
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stimates o Quctine size are converted *o costs using 


Meee per instruction values that are functions of the 
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routine type and complexity. The costs are fully burdened 
and when summed for all the system routines represent the 
total system development cost. Development extends from 
analysis and design through operational demonstration. A 
matrix of ratios is used to allocate the total cost to 7 
phases with each phase divided into up to 25 activities. 
This allocation is compared from the standpoints of staff, 
schedule, and general credibility. 

The model, then, isa combination of formal algorithm 
and judgement. It has been used successfully at TRW. As 
described by Wolverton, it features a data base of histor- 
ical data that provide the necessary cost per instruction 
and allocation values. The procedure is adaptable to any 
new environment by creating a new data set representing 
local definitions of phases and activities and burdened cost 
conventions. In fact, Wolverton cautions that the given 
values cf cost per instruction are for illustration and 
users should prepare their own values. 

TRW has computerized the maintenance of the cost data 
base and the allocation process. Given the inputs of siz 
and complexity, the system calculates the cost allocations 
and facilitates any subsequent adjustments. Since mos* 
models are used in a similar manner, e2ven if the procedure 
for uSing the model does not say so, there should be no 
compromise of the model's performance if the evaluation is 
based on a single estimate of costs. Other adjustments that 


are necessary to execute the model in different environments 


}— 
ow 
Om 


we 2 discussed later. 
Mac eStinating procedure begins by identifying all the 
né comprising the system. Each routine si Catzecqcocry, 


Ze, 
elative degree of difficulty are estimated by knowl- 
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The categories that have "stood the test of usage" at 
TRW are: 
e® Control routine 
e Input/Output routine 
e Pre or Post algorithm processor 
e Algorithm 
e Data Management routine 
© Time-Critical processor 

Relative difficulty is indicated by six levels depending 
on whether a routine is Old or New and then by simply: Easy, 
Medium or Hard. 

Seeatultiplying the cost per instructin for each 
routine by its number of object instructions and summing the 
products for all the routines yields the estimated total 
development cost. 

The development cost is allocated to the following 7 
phases using proportions for each phase that were obtained 
from the historical data base. 

A. Performance and Design Requirenents 
B. Implementation Concept and Test Plan 


C. Interface and Data Requirements Specification 


D. Detailed Design Speci fication 

pee COG Ng and Auditing 

PF. System Validation Testing 

G. Certification and Acceptance Demonstration 


Then, the cost for each phase is divided into up ¢o 25 


meruvyities..ee 


$+ 
UW 


A matrix of computer hours by phase and software type 
used to estimate computer usage costs for devslopmen+. 
Que puts 


evelopment Cos: 


The given cost values are in 1972 dollars. The value of 


Soseesesults from apolying "Sid rates" to labor costs which 
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accounts for fringe benefits, overhead, administrative 
expenses and other indirect costs. Documentation and travel 
costs are added to the labor costs. Pinally, estimates are 
made of the computer costs. The distribution of the costs 
by phases and activities were described above. 
Development Effort 

Cost is not a suitable basis for evaluating the 
different software estimating models because of differences 
in accounting practices among organizations and because of 
ma tation. Therefore, the Wolverton cost values were 
converted to manmonths using an average burdened cost per 
manmonth of $4600. This value was obtained from the article 
describing the TRW estimating procedure and, therefore, 
should te representative of the cost environment. 
inputs 
Object Instructions 

The model input measure of size is applied to prograns 
or routines. These are taken to be functionally distinct 
elements of a system that would be developed independently 
then intergrated into the delivered systen. It is expected 


that these would be indevnendently operable using test 


drivers. Such a definition is consistent with industry 
usage. The reference document is not specific on this 
point. The tern “instructions" is taken literally. fas 


means estimating the number of instructions in the execnu- 


ae | 


sable program exclusive of any data areas. number of 


iD 


h 
h 


= 
memory occupied by the executable code and dividing by the 


ct 


instructions may be estimated by obtaining words of 
average words per instruction. 
softwares Cateqories 


Baen TOULTISe i 
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Gaapaecter Zeq acCcOzding £060 one of 


Ss 
following categories: 
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Se. Comerol Routine. Controls execution flow and is 
Heneame Clitacal. 

fimeanput/Ourcput Routine. Transfers data into and out of 
computer 

P. Pre-or Post Algorithm Processor. Manipulates data 


for subsequent processing or output. 
ae 60ALGori*hnm. Performs logical or mathematical opera- 
tions. 


Dee Data Nanaq 


iD 
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Manages data transfer 
within the computer. 
T. Time Critical Processor. Highly optimized machine 
dependent code. 

Wolverton indicates that any numeric representation of 
complexity may be used. Th2 main purpose is to distribute 
the cost per instruction values over the range of experience 
for a given category of software. He suggests a simple 
designation of old or new, depending on a loose intervreta- 
tion of the amount of reusable cod2, and easy medium or hard 


compared with other programs in the same category. 
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A. INTRODUCTION 


R. W. Wolverton studied several software cost estimating 
models while working for TRW in an effort to determine that 
model which would best predict +hose costs associated with 
software development. This appendix consists of excerpts 


from his review of some of these models. 


Be BOEING COMPUTER SERVICE COST MODEL 


Purpose 

Boeing Computer Services (BCS) designed this analytical 
model to provide an estimate at proposal preparation time of 
the number of manmonths needed to design a computer progran. 
BCS developed the model for use as an internal guideline +o 
cross-check the traditional bottom-ud estimate nade by their 
proposal manager. The bet+tcm-up estimate, with its WBS was 
tacitly assumed to be more accurate and the model served to 
aid in independently justifying the proposal manager's 
estimate. 

While under contract to RADC, Boeing used their cost 
model +o test several hypotheses about the cost benetfi+ 
Secrabutable to modern programming practices (Black, e* al., 
ere: Black, 1978). BCS derived and calibrated their nodel 
against Beech @ale soOrtware projects using weeds =ional 
programming voractices. This model has raceived wide-spread 
exposure as part of the DOD's embedded computer resources 
DSARC guidebook {DeRoze, 1977). 
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Input 


ae 


Size of computer software in units of delivered 
source statements. The BCS model assumes that a 
"statement" is one fully checked tested, and docu- 
mented statement coded in a selected language. The 
choice of high-level language can have a significant 
effect on the development cost, but ordinarily affects 
only portions of the total task. 


Type of software to developed. BCS observed some 
eombpinatz2on of five generic functions. Each "type 
has its own group productivity rate. The specific 


software type and productivity rates are as follows: 


e Mathematical Opns 6 manmonths/ 
1000 source statements 

e Report Generation 8 manmonths/ 
1000 source statements 

e Logic Operations 12 manmonths/ 
1000 source statements 

e AAG) seh Processing, 40 5 manmonths/ 
a Reduction 1000 source statements 

e Real-Time, Executive or 40 manmcnths/ 
Avionics Interfacing 10090 source statements 

The decreasing productivity is caused by the 


increasing complexity of the type of software being 
developed. 

Tasks to be accomplished in the computer software 
development, are distributed by the BCS model as 


fTcollows: 


Task & Total Cost 
e Requirements Definition 5 
e Design and Specification 25 
ae GOde Preparation 10 
e Code Checkout 22 
e Integration and Test ZZ) 
e System Test 10 


Oe 






The numerical distribution opposite the task does not 

consider reuse and sophisticated debug tools. The 

distribution is not necessarily a rectilinear function 
of time, but is intended to be used as & guideline for 
schedule preparation. Documentation is not included 
in this estimating procedure and must be estimated by 
scme other method, not defined in the model itself, 
and added to the manpower estimates. 

d. Adjustment of the labor estimates 1S accomplished by 
means of table lookup multipliers given in Table VIITI. 

All terms are assumed by the model developer to be 

self-explanatcry. 
Computational Procedure 

Using this model, Program Office personnel would esti- 
mate how much of the total OFP software is closest repre- 
sented by one of the five generic tyves of software. In 
practice, estimating the size and type would be based on 
past experience with similar projects that have been 
adjusted to the new application. Everything associated with 
the manmonth estimate flows from this first step. 

Table VIII provides the estimator with phase-sensitivs 
multipliers for adjusting the baseline manmonths estimate. 
The user should be alert to stringent sizing or timing lini- 
tations. These effects should be 2stimated by some cther 
procedure (not given) and added t9 the baseline manmorth 
estimate. 

After individual labor costs have been adjusted by usa 
of the table, the BCS model sums up the individual estinates 
Bm@eeeeerncives at the ‘tctal labor cost for the project. 
Computer time is estinated by a rule of thumb that approxi- 
mately three hours cf stand-alone computer tine will be 


Spent per manmonth. 
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Out put 

The fundamental output is the total manmonths estimated 
for the planned software project. Piece toe) tOcal 
Manmonths are spread over a six stage development cycle from 
requirements definition to system test. 

Although acceptable engineering accuracy in estimating 
total manmonths is claimed by the model developers for 
traditional programming practices (c. 1970), the axampvles of 
estimating accuracy are not encouraging for modern progran- 
ming practices. In other words, the intent of the BCS model 
is to show how much anew project would have cost if done 
the old way. Presumably the lower observed cost is due to 
the new design nethodologies. Output results for five 
projects given by BCS are shown in Table IX. A guideline is 
to try this model cn some historical data and compare the 
accuracy of predicted versus actual mManmonths before 


attempting to usé it in practice.... 


TABLE IX 


Forecasted versus Actual Costs for the BCS Model 


—— 1 —— —— 
| Forcast | Actual |Porecast/actual| 
| Project{ Total Manmonths| Total Manmonths Ratio 





| A G19.7 Tt ae, | 
| B | 22o8 = 2 | 991. 7&% | ZaS | 
| c | SG = } 43.8 Aw: | 
| D | BSS aly | | 514, 8% | 6.4 | 
ir . ig | _ TTS, ! od | Pe | 








m% Contains some estimacte-to-complets data, along with 
actuals 
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C. IBM WALSTON-FSELIX COST MODEL 


Put pose 

Walston and Felix conducted experiments on 690 completed 
software development projects in their search for a method 
of estimating programing productivity (Walston-Felix, 1977). 
The purpose of this effort was +5 estimate the rate of 
production of lines of code by projects, as influenced by 
project conditions and requirements. 

Five specific cbjectives of the Walston-Felix model are 

a. To evaluate improved programming technologies. 

mee LO §60—provide Support for proposals and contract 
performance. 

¢c. To gather historical records of the software devel- 
opment work performed. 

d. T0 provide programming data to management. 

e. To foster a common programming terminology. 

Completed projects in the Walston-Felix data base ranged 
in size from 4,000 to 467,000 delivered source lines of code 
mm@man effort from 12 to 11,758 manmonths. Applications 
programs included realtime process control; interactiv2, 
report generators; data base control; and message switching 
programs. Twenty-eight different high-level languages and 
66 different comnputers are represented in their data base. 
This is an outstanding example of a closed-form nodel 
obtained by linear regression analysis of a large and 
diverse body of actual software projects. Some further 
technical work is required to extend the findings of Walston 
and Felix to the specialized needs cf avionics software. 
The additional work to be done in calibration of «the nodel 
Will be discussed in...Computational Procedure. 

ae Number of lines of delivered source code. Source? 


lines are 80Q-character source records provided as 





input to a language processor. Job control languages, 
data definitions, link edit language, and comment 
lines are included. Reused code is not included. 

b. From the raw data provided by the 60 projects, a set 
of 68 variables was selected for analysis to find 
which ones were significantly related +o vroductivity. 
Twenty-nine of the variables showed a significant 
correlation with productivity and have been retained 
for use in estimating.... 

C. eeee-The model user is asked to answer a multiple- 
choice question in his response to the statement: User 
participation in definition of requirements is: none, 
some, much. In the origional analysis the mean 
productivity was computed for the 60 completed 
projects for which no user participation was reported 
and found to be 491 DSL/MM. The mean productivity for 
all projects that reported some user participation was 
267 DSL/WH, and the mean productivity for those 
reporting much user participation was 205 DSL/MM. The 

absolute value cf the change in productivity from no 
user participation to much user participation is found 

me pe 286 DSL/MM.< ee 
The Walston-Felix cost model can aid Program Office 
personnel in estimating five project parameters: produc- 
tivity, schedule, cost, quality, and size of the software 
product to be delivered. Once de tivey lay is in identifying 
and measuring indevendent variables that can be used to 
estimate the desired variables, such as estimating the size 
Mmmmens SCttware product *o9 be delivered. We take the point 
of view that the size of the software product +o be déliv- 
ered can be independently, albeit with difficulty, estimated 


From the internal historical data base associating avionics 


ke 





function with size (Battelle, 1978) One sev2Onzes function 
with software requirements {Heninger, st al., 1978). 

Productivity is a significant variable in all software 
estimating frocesses. Programming productivity is defined 
here as the ratio of the delivered source lines of code 
(DSL) to the total project effort in manmonths (MM) required 
to produce the delivered product. Total manmonths covers 
the management, administ sation, analysis, operational 
support, documentation, design, coding, and testing effor+ 
expended in the development phase. Analytical results are 
meraved at start of work, PDR, midway through software 
development, at acceptance test completion, and every three 
months during the service or maintenance phase. 

The 29 variables...ar2 combined into an index based on 
the effect of each variable on productivity from previous 
analysis. The productivity index is computed as follows: 


i “> AX. 
4=1 2 2 
where 
a0 = productivity index for a project 
4, = question weight, calculated as 0.5 eee US) 3 
(PC). = productivity change indicated for a given 
Guest ions... 

i = guestion response (+1, 0, or ~-1), depending on 


whether the response indicates increased, nonm- 
inal, or decreased productivity. 
ecesthe data set is analyzed by ordinary least squares 


mogmerne Stancard error of astimate, or standard deviation of 


Beetatals, is shown as dashed lines. In the data samples 
Stucied, the productivity index ranged ‘from -4 +0 +4 
(private communication with C. WaLStOn) < The Air Force 


model user would determine his own productivity index 
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Singie project by answering the 29 questions...and bv 
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calculating I according to the above formula. He then 
multiplies his average productivity for all past avionics 
software in his data base by the productivity index for the 
acquisition at hand. 

If the Program Office has a historical data base of many 
projects, the total effort can be determined by a least 
squares fit andthe cregression equation from the Progran 
Office's own internal data analysis at the point I= QO, 
DSL/MM = 274, using the coordinate system.... A statis- 
tical analysis program such as the Statistical Package for 
the Social Sciences (a product of SPSS, Inc.) would be 
helpful. SPSS will also provide other descriptive statis-~- 
tics such as the standard error of the linear regression 
os es 

The statistics...are given by medians and quartiles 
because cf the variability in the measurement data. Note 
that the median productivity (I = 0) is 274 DSL/MM. The 
median for the size of the delivered software product is 
20,000 lines; 50 percent of the projects reported that the 
size cf their delivered code ranged from 10,000 to 59,000 
lines. Resources for oroject development are shown. The 
error detection results are for the distribution of errors 
reported during the development period.... 

The amount of calendar time to allow for the development 
Sew software is difficult to express from a closed-forn 
model. However, the equation for project duration in nonths 


meme cunction of total effort in manmonths was found to be: 


0235 
Wea ed) S 
where, 
M = duration in months, for full-scale development 


E = effort in manmonths, for fFull-scale developmenc. 





From the data collected for service projects, certain 
descriptive statistics were calculated.... The interpreta- 
tion is the same as before: median data and quartile data 
are presented due to the scatter in the raw reports. No 
predictive relationships are given for service projects. 

Documentation, as defined in this model, consists of 
program functional specifications and descriptions, users! 
guides, test specifications and results, flowcharts, and 
program source listings that are delivered as part of the 
documentation. To a close approximation, the least squares 
equation for «he number of ovoages of delivered documentation 


varies directly as the number of lines of source code; that 


is 
Bee uoen 
where, 
D = pages of documentation, including source listings 
L = thousands of source code lines 
Qut put 
The major outputs available to the mcdel user are as 
follows: 


a. Total effort in manmonths reqnired +9 vroduce the 
lines of source code. 

Dee Duration of project in months. 

Cc. Use of improved programming technologies expressed as 
a percentage of code develoved using each technique. 

d. Estimated productivity of project as influenced by 


project environment and requirements. 


(D 


- Pages of documentation for the intended PEelce =, 
including pages of source listings delivered as part 
of the documentation requirements. 

f£. The resuits de not Support answers to Cetitasn 

preject attributes implied by the data coeffi- 


GZeEntsS...because of cross~correlation effects (i.ée., 





the individual attributes are not statisticlly inde- 
pendent). For example: 
1. Chief programmer team. 
2- Top down development. 
Si. tructured programming. 
4. Design and code inspections. 
The contribution of each attribute could not be taken 
individually because in the deramrcion or ~ chief 
programmer team the other techniques are implied. 

ge Other descriptive statistics can be inferred from 
study of the report itself; for example, the cost of 
computing time and the average number of people jtotal 
manmonths of effort divided by the duration) as a 
GanerlOon Of the total effert. The responsibility of 
relating the lines of executable assembly code to 
lines of delivered source cod@ rests with the model 
user.... A scaling law for the Walston-Pelix model can 


be derived from internal avionics historical data. 


Meera > SOFTWARE LIFE CYCLE COST MODEL (SLIM) 


Pur pose 

A descriptive cost nodel, coupled with informed ecpinion, 
Will aid in answering top-level management questions about 
the development cf OFP software. Descriptive statistics 
associated with expected OFP software cost, A€svelopment 
time, manning levels, and perturbations about these esti- 
mates are Significant management interests at pre-RFP time. 


The Air Force can specify a useful lifetime, say 10 yeats, 
n 


wW 
Oo FR 
bet, 
ct 
ke fe 


ena obtain a quantitative cest esti: S208? Software 


lize cycle subject to the assumptions 
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Input 
Three input parameters are required to calibrate this 
model's technology constant (Ck) for avionics applications. 
The F-111 data point...was the basis for ‘this calibration. 
The three data points are: 
ae Number of delivered lines of executable source code, 
not including comments: 22,100. 
b. Number of manmonths for developing software: 805. 
Cc. Number of calendar nonths for developing software: 33. 
The user 1S prompted for all inputs by the EDITOR built 
into the SLIM cost model. Seventeen on-line inputs required 
for this model are as follows: 
a. Enter title of software system. Avionics, F-111 
b. Enter start date (MMYY). 0174 
ce. Enter the fully burdened labor rate ($/MY) at your 
orgainization. 60000 
d. Enter the standard deviation of your labor rate 
($/MY). 6000 
- Enter the anticipated inflation rate as a decimal 
meaceione 0.065 
iriter the proportion of development that will occur in 
On-line, interactive mode. 0 
See Bunter the proportion of the develooment computer 
that is dedicated to this system development effort. 
On 2 
he. Enter the proportion of the systen Sate Leo De 
coded in a HOL. 0 
meee sater the humber corresponding +to zhe primary 
language to be used. (twelve choices are given.) 10 
= assembly level Language. 
fe Enter the number corresponding to the ‘type of your 
system. 1 
lee Real=tane or Sime critical systen 
2 


- Operating systen 






Qe 


Ne 


Sa GConmand and control 

GW. Business application 

5. Telecommunication and message switching 

bea scientific systen 

7. Process control. 

Choose the response below which best describes your 

system. 2 

1. The system is entirely new, with many interfaces, 
and must interact within a total management infor- 
mation system structure. 

2. This is a new stand-alone system. It is simpler 
because the interface problem with other systems 
is eliminated. 

3. This is a rebuilt system with large segments of 
existing logic. The primary tasks are recording, 
integration, interfacing, and minor enhancements. 

4. This is a composite system made up of a_ set of 
independent subsystems with few interactions and 
interfaces among then. Development of *+h2 ind:2- 
pendent subsystems will occur as a considerabls 
overlap. 

5- This is a composite system made up of a_ set of 
independent subsystems with a minimum of interac- 
tions and interfaces among them. Development will 


occur in parallel. 


Enter the the proportion of memory cf the target 
machine that will be utilized by the software systen. 
On 95 

Eote= Che Proportion of real-time code. 1 

Below is a sét of modern orogramming techniques 


that may be used on a software development project. 
ab 


Beside each are thre possible 
the degree of usage on your systen. 


bespenses indicating 


ad 
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22> =P 22 eee 22 eee ee ee eee See ee ee ee ee ee Se ee eee SP a SP ee ee es es a ee ae ee ee ee eee ee 


Structured Programming 1) < 25% 
Z) 25-7 5% 
3) >75% 
Design and Code Inspection 1) < 25% 
2) 25-75% 
3) > 75% 
Top-dcewn Development 1) < 25% 
2) 25-75% 
3) > 75% 
Chief Programmer Teams 1) <25% 
2) 25-75% 
3) >75% 
Oo. Below are two indicators of personnel that can 


impact the cost and time to do a project. Beside each 
are three possible answere indicating the degree of 


experience. 2 


Overall Skill and Qualification 1) si ninmal 
2) Average 
3) Extensive 


With Development Computer Vy etans nat 


PMe2t Sizing information in one of two forms: 

le An Overall range of sizes, OT 

2. Ranges of size on 2 nodule-by-module basis. 

Poe lamers 2 ee tOusnadacate how Sizing data should be 


entered. 1 
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qe Enter the lowest possible and highest possible size in 
source statemerts. 18100, 26100 
Computational Procedure 
Total effort can be determined from the software equa- 
tion developed by L. dH. Putnam (Putnam, 1978; Putnam and 
Fitzsimmons, 1979). Th2 software equation is modified by 
the environmental input parameters, items f through o. The 
software equation is: 
Borer lal 
s K q 
where, 
S = number of delivered lines of executable source 
i code, net including comments 
c =a state of technology constant; previous exper- 
1énce with computer response times and pro- 
gamming practices gives: 


- = 754 for avionics, assembly-level language 


Eo, = 4984 for "1973-style" arbitrary develop- 
nent 
o, = 10040 for "1979-style" structured develop- 
nent. 
K = Rayleigh/Norden life cycle effort parameter in 


units of manmonths or manyears 


ce 
\ 


= Rayleigh/Norden time parameter. Time at which 
peak manpower nominally occurs for large soft- 
ware projects. Mathematically, it is the peak 
Pare Curve, 


2 
; =e72 
yaa Kc ze d 


SA SESVeeeneGereaculty, Or tatio of total ¢ffocrt to 


development ime squared. 





The software equation is used to obtain engineering 
quality estimates during the early phases of a software pro- 


ject. The software equation is solved using a gradient con- 


Straint, K = VD oe where the magnitude of the difficulty 
gradient is empirically found for a particular development 
environment. Monte Carlo simulation is used to generate 
descriptive statistics associated with the effort, develop- 
ment time, and development cost. The standard deviations 
are used in calculating risk profiles. 

ae effort, time, and cost point estimates can be 
presented in the form of probability plots assuming a gaus- 
Sian distribution. All that is needed is an extimate of the 
expected value (plotted at the 50 percent probability level) 
and the standard deviation (plotted offset from the expected 
value at the 16 percent probability level) +o generate the 
probability line oon ordinary probability paper. Then one 
can determine for example, that there is a 90 percent prob- 
ability that the software development will not take more 
than x-manmonths cf effort. When repeated for all prob- 
ability levels of interest, one has a risk profile for that 
estimate. 

The tradeoff law can be obtained fron the software equa- 
meen ty solving for K. Ach a Mont CayelO Si au lation for 
generating variances for K and td one can perform a tradeoff 
analysis, pick a reasonable effort (or cost) time combina- 
tion and complete the sensitivity analysis. The value of 
Simulating several thousand Mont2 Carlo runs is that it 
produces a measure of the variation in effort and develop- 
Meee me, OF “he risk vrozile. Know2ng the sensitivities, 


2 
ema’ S Force PM can use it effectively in olannin a! 


7 8 


contracting so that the risk level is always within acce 
range. Examples of this procedure are given in + 
Sac 77 tutorial (Putnam and Wolverton, 1977). 


de 






Qut put 





editor, 


Was 


data, 
was acceptable. 


Three options 


Nestimate." A 


*#he 


The option chosen for this illustration 


are available to woe: calibrate, 


estimate. 


file is built from the previous input 


and an on-line comment shows that the input data check 
of the 


The structure On-line output is 


shown below: 


Ae 


table of 
the technology constant, 
754. 


system cost summary is given as follows: 


Summary of input parameters: all inputs. 
Annotated comment shows Ck, 

WwaS separately computed to be 
S2 mu Lat Lon: 


=—_ <> <—becmp “EP <p D> <p ce SP es es es ee ee eee ee ee es ee eee es ee ee ee ee ee 


Mean Std Dev 

System Size (STMTS) 22100.90 133350 
enone eee time 34.8 Tiee2 
Development Effort (Mannonths) 891.0 106.9 
ee euvet seca dotiacs 4461.0 TAO 

= Inflated dollars 4887.0 T3770 
SenslLeLvley DLOtaLe fOr minimum time solution 
fees, expected valuss of time, effort, and cost for 


the whole size profile): 


=> EP cb <P <P ee ee ee ee ee ee ee es es se ee ee se es ee ees ee ee ee ee ee a 


a Statements Yonths Months (x $1000) _ 
-2 SD 18100 3129 So 2629 

-~1 SD 20767 33.9 7§3 3814 

Most Lixely 22100 34.3 891 4461 

+41 SD 25433 35.5 1034 Sih tee 

+3 SD 26100 37.3 1331 6657 
ee |... ------------- 
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ds. A cross-check with data from other systems of the 
Same size for the most likely estimates is given. As 
compared with the RADC data base (which is a mixture 
of software projects), the remarks show less than 
nermal productivity fer avionics OFP software. This 
is to be expected. 

e. An on-line information note gives the user 14 options 
for the remaining output; several of these will be 
given to show the management parameters available. 

f. Linear program: this function uses the technigue of 
linear orogramming to determine the minimum effort 
(and cost) or the minimum time in which a system can 
be built. The results are based on the actual 
manpower, cost, and schedule constraints of the user, 


combined with the system constraints provided earlier. 


1. Enter +*he maximum development cost in dollars. 
4560000 

2. Enter maximum development time in months. 36 

3. Enter the minimum and maximum number of people 
allowed on board at peak manloading time. 15, 40 


-_—_ Pp aD 4 SO OP a Oe eee Se ee eee ee eS ee ee ee ee ee ee ee a ee ee ee ee ee ee a ee a ee ee ae ee ee ee 


Cost 

Tine Betors {x $1000) 
Minimum Cost 36. 00 4on=hs 778 MM 3892 
Mininun Time 34.8 Months 889 MM UUN6 


g- A tradeoff analysis within these limits is shown 


below. 
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=_ wep e® ap ae oP ae? abee® oF a eee 22 8 GE ae em oP OF aE awe 6) ee ee eee eee ae Pee ee eee ee eee ee Se eee ee eee ee ee ee ee es 


34.8 889 YUU6G 
Boo 869 4345 
B56 2 849 Q247 
35. 4 830 4152 
35.6 812 R059 
Se te 794 3970 
36.0 778 3892 
h. Front end estimate: recall that the SLIM model 


assumes that the estimated time length is from logic 
design. Therefore, a separate front end estimate is 


required, as fcllows: 


Time (months). Econ ait 
(L) E) (H) (L) (4) (4) 
Feasibility Pate: Say 9.6 9 35 61 
Scud y 
RunG= Lona. 1024 11.6 V2.0 Zs 210, 1 
Desian 


Note: L = Low, E = Expected, H = High 
i. Manloading: The table shows the nean vrojected effort 
and associated standard deviations required for deval- 


opment. The input oarameters are 


Mean Std Dev 
Development Effort (Manmonths) Sasha] 18, VOG. 2 
Development Time (Months) 3423 Iie2 


=_ DP =aEPaewaw 2S aPe awa @Peaw ase ase aes eae awe awe aweeaw Re ee eee eee ee eee ewe aw See eee ee Se ee ee Se eee ee ee ee SE eee ee ee ee ee ee a a = a 





> <p ee eo ee ee eee ee ee eee ee ee ee ee ee ee ee ee es ee ee ee ee ee ee ee 


CRE Cumulative Cumulative 
Time Mont Std Dev Manmonths Std Dev 


> <p ED ap eee ee ee ee ee ee ee eee ee ee ee ee ee eee ee ee es ee ees es es es es es es es es se es es ee ee 


Jan 74 0 2 0 
Feb 74 5 1 
Mar 74 1 16 Z 


Oct 76 17 2 877 105 
Novy 76 15 2 893 107 
Dec 76 7 1 900 108 


— <P ee ce Pee eee ee <a ee ee eee ee ee ee eee a es ie ee eee ee ee a 


Gonos  d2stribution of 36 rowS is essentially a 

Rayleigh distribution over the calendar period of 

performance, with integer values for all entries.).... 

Other primary outputs from the Slim cost nodel 

include: 

1. Code production: calendar time versus cumulative 
source statements 


2. Computer usage: calendar time versus CPU hours 


3. Documentation: expected number of pages of docu- 
mentation 
&. Deéesign-to-cost: SLIM has provided its best esti- 


mate of the minimum time and corresponding maxinun 
effort ( and cost) to develop your systen. A 
greater effort would result in avery risky time 
echedule. However, if a lower effort is specified 
(within reasonable limits), development is still 
feasible as long as more time is allowed. 


Entered desired 2ffort in nanmnonths. 305 





New Development Time (Months) oa 7 eZ 
New Develorment Cost (x $1000) $4025 488.0 


5. The original file is updated with these new paran- 
eters, and the user can run manloading and cash 
flow or life cycle to see how these savings can he 
realized. This can be used interatively to match 
some projected benefit stream and get the project 
approved. (Connect time was about 37 minutes to 
EQN Sled at a cost of about $25) 

In summary, the SLIM model is a descriptive, macro-level 
cost estimating tool applicable to OPP software, provided 
that its technology constant (Ck) is calibrated from valid 
MmestOrical OFP project data: number of delivered lines of 
executable source code; number of manmonths from project 
start tc software acceptance; and number of calendar months 
for the development. This step and its consequences must b¢4 
understood by the user. SLIM composes the feasibility study 
and functional design as a separate front-end estimate which 
must be added to the initial cost estimate. Labor mix and 
work breakdown structure Pitorna £2 on LIEN ejee qaavens 
Resources are allocated against time (spread by a Rayleigh 
Beet 2bution), but not against function (e.g., analysis and 
design, code and debug, and test and integration). All 
Statistical parameters are assumed to be normally distrib- 
Pe-a,fOr mathmematical tractability. This assumption may 
contribute to the extreme sensitivity between minimun cost 


and minimum time as shown in item £, linear program example; 


j- 


ope a «3S Percent change in calendar tine (from 36 to 34.8 


months) corresponds to a 14 percent change in cost ($3892K 
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to $4446K). All mathematical expressions used in the compu- 
tational procedure are continuous functions; therefore the 
model will always produce a calculated estimate. AS with 
all models, this estimate must be tested against experience 


and human insight. 
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TABLE X 
Project A Data 
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TABLE XI 


Project B Data 
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TABLE XII 


ojyect C Data 


i 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


| 
0 | 
UO 
G | 
18] 
es | 
» | 
re) 
Fr ( 
-— i 
= | 
b 
i WMMMOAHANG 
i © | NasroOortrroncocem 
qa Or HnoOrrowor 
en | TMNAMOOCWMMA +t 
OG | WNOMMmeMAW 
“ri eevee eveeee 
wes ft Ole ANMMMNM 
ac | 
id | 
QQ: =: | 
= 
~~ 
3 | 
0) ee eae eae eae ie ge es cin 
+ Y) TFmMATFTOMAHADHAWDOEFrAMNANWOARMAoOwoowrm 
Oe 1 NrKWOOME OF KDUKNWOOMOMUWUrOrnrNne 
orf 4) | DWINDOM HM AON 2 FAHM™ AMMA COMK Dw 
w?Ww & *eeesrter eveereeeeee wee ee el eh elt le 
W ct ee eee eS MANITTOS 
Hi wd lh mel eel med veel SUE saad, moll ela mad 
Py ES 
| 
| 
oe 
= ee 
orf | aa ccag MNS tela ba RA 8 
es SE ONAN ANN 
i 
u | 
ae | 
wo 4 
~& | 
PH J DNOMMNMNHDOCAODCDOOCOCDVCCVDOCOMCOO 
Ud | eee evrnscrVerevr 7 eve eo gscveeregeertee 
ro oH | WMO ONNM 2st TMK HK ODAHMANANN SIMs 


i 
: 
| 


eS a a 


130 





Tapes xk ii 


Project D Data 


tenance | 
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